How to work around FORM method="post" changing "." to "_" please?

here is my form:

Re: How to work around FORM method="post" changing "." to "_" please?

In our last episode, <1192370117.737201.79970@k35g2000prh.googlegroups.com>,
the lovely and talented william.hooper@gmail.com broadcast on comp.lang.php:

> So the Post method is changing "." to "_"

RTFM. Chapter 65. Question 2.


--
Lars Eighner
Countdown: 464 days to go.
What do you do when you're debranded?

Re: How to work around FORM method="post" changing "." to "_" please?

That's a manual... Is it online - what is RFTM I can not find it on
google please.

I tried urlencode and rawurlencode but they do not do the trick.

Re: How to work around FORM method="post" changing "." to "_" please?

Oh I found...

http://www.encyclopediadramatica.com/index.php/Rtfm


Abbreviation for "Read the Fucking Manual". It refers to the manual
pages (or "man" pages, after the command used to display them)
contained in *nix variants and has mutated to refer to reading any
help pages or FAQs. Typically used as a reponse on mailing lists and
in chat rooms when a newbie asks questions for which the answers are
readily available from other sources. Even then, some people are too
retarded to bother. It is expected that if you want to play in places
like misc@openbsd that you have already done your homework, or
RTFM'd.

I am a newbie, but please if you could tell me what manual...

Re: How to work around FORM method="post" changing "." to "_" please?

Here is a manual... http://www.php.net/manual/en/ but it has no
chapter 65 and it looks quite long...

Re: How to work around FORM method="post" changing "." to "_" please?

On Sun, 14 Oct 2007 16:16:27 +0200, wrote:

> Here is a manual... http://www.php.net/manual/en/ but it has no
> chapter 65 and it looks quite long...

It has, he's referring to:
http://www.php.net/manual/en/faq.html.php#faq.html.form-imag e
(wouldn't say it's easy to find though, with your particular problem, as
it has nothing to do with the 'image' it's referring to)

Short answer: you cannot use a dot in names. (It's probably a lousy
inheritance from the 'register_globals' directive, as normally an array
key can contain a dot without any problems.

Solution (in order of my own personal preference):
option1: create (unique) identifiers for the files in your directory, and
use those instead of the 'real' name.
option2: get the filename to the script as a value rather then a key
(using a checkbox & 'delete selected' button for instance).
option3: use a different

Re: How to work around FORM method="post" changing "." to "_" please?

In our last episode,
<1192371387.911013.31070@q3g2000prf.googlegroups.com>,
the lovely and talented william.hooper@gmail.com
broadcast on comp.lang.php:

> Here is a manual... http://www.php.net/manual/en/ but it has no
> chapter 65 and it looks quite long...

http://www.php.net/download-docs.php

Yes, it is several megs depending on format.

However, you should realize that many of your questions reveal that you do
not know HTML. The PHP manual will not teach you HTML.

If you had looked in your copy of your HTML dtd (this happens to be
4.01 strict, but you'll find something similar in your dtd)


%attrs; -- %coreattrs, %i18n, %events --
action %URI; #REQUIRED -- server-side form handler --
method (GET|POST) GET -- HTTP method used to submit the form--

This should have told your that method defaults to GET.

I don't know if the PHP manual mentions this, but it isn't PHP's job to
teach you HTML.


For example, your latest question here was based on the theory that POST
will change periods to underscorces. POST does not do this. PHP does this
under certain circumstances and will also change space to underscores under
certain circumstances (because PHP variable names cannot contain periods or
spaces).

This does not pose a problem for most people because most people do not
expect to have both foo_jpg (no extension) and foo.jpg. Yes, if you do
have an image named foo_jpg (no extension) then some ambiguity could
result. But sane people do not name images foo_jpg (no extension).


--
Lars Eighner
Countdown: 464 days to go.
What do you do when you're debranded?

Re: How to work around FORM method="post" changing "." to "_" please?

On Sun, 14 Oct 2007 16:54:50 +0200, Lars Eighner
wrote:
> This does not pose a problem for most people because most people do not
> expect to have both foo_jpg (no extension) and foo.jpg. Yes, if you do
> have an image named foo_jpg (no extension) then some ambiguity could
> result. But sane people do not name images foo_jpg (no extension).

Then again, sane people realise it's just a matter of time before someone
is so insane to do just that. Certainly for deletions, there must be no
chance of ambiguity on what to delete, however small it might be.
--
Rik Wasmus

Re: How to work around FORM method="post" changing "." to "_" please?

Rik Wasmus, Thanks so much I have credited you on my upload page
saying thanks for the help! All done now!

Re: How to work around FORM method="post" changing "." to "_" please?

Oh I used "option3: use a different for each file in your
interface, and give
it a hidden INPUT with the filename" by the wa. I would never have
gotten there without you!

Re: How to work around FORM method="post" changing "." to "_" please?

On Sun, 14 Oct 2007 18:28:58 +0200, wrote:

> Rik Wasmus, Thanks so much I have credited you on my upload page
> saying thanks for the help! All done now!
>

Hehe, make sure you get the security right before you attach my name to it
:P. What happens if I build a POST request that tries to delete
'../index.php'?
--
Rik Wasmus

Re: How to work around FORM method="post" changing "." to "_" please?

oh dear... i better fix that one

Re: How to work around FORM method="post" changing "." to "_" please?

On Sun, 14 Oct 2007 18:36:19 +0200, Rik Wasmus
wrote:

> On Sun, 14 Oct 2007 18:28:58 +0200, wrote:
>
>> Rik Wasmus, Thanks so much I have credited you on my upload page
>> saying thanks for the help! All done now!
>>
>
> Hehe, make sure you get the security right before you attach my name to
> it :P. What happens if I build a POST request that tries to delete
> '../index.php'?

Hmmmmz... anything can be uploaded?
I have redirected your site to some reading material on google...
--
Rik Wasmus

Re: How to work around FORM method="post" changing "." to "_" please?

Oh got thats quite funny but a bit scary!
I am a fool

Re: How to work around FORM method="post" changing "." to "_" please?

On Sun, 14 Oct 2007 18:59:14 +0200, wrote:
> Oh got thats quite funny but a bit scary!

Scary indeed :P

> I am a fool

Well, you've got something to learn, have fun :)
--
Rik Wasmus

Re: How to work around FORM method="post" changing "." to "_" please?

Thanks very much for all your help- relly fantastic.

So so everyone on google groups knows... my upload had a flaw to Rik
rewrote some of web pages!!!

Re: How to work around FORM method="post" changing "." to "_" please?

Sorry... typo...

Just so everyone on google groups knows... my upload had a flaw so
Rik
rewrote some of web pages!!! Kindy he disabled my upload and pointed
it to some security articles on google!

Re: How to work around FORM method="post" changing "." to "_" please?

On Sun, 14 Oct 2007 19:03:52 +0200, wrote:
> Thanks very much for all your help- relly fantastic.
>
> So so everyone on google groups knows... my upload had a flaw to Rik
> rewrote some of web pages!!!

Well, I only disabled your index page. Theoretically uploading and
deleting is still possible.

And this is not Google Groups BTW: This is usenet, Google Groups just
happens to have an interface to it.
--
Rik Wasmus

Re: How to work around FORM method="post" changing "." to "_" please?

Yea it was very cool - I am not complaining, I am laughing at myself!

I guess you did that by uploading a php file that allowed you to look
at other directories?

I have to make sure strings starting with "\" or "." and i must also
disable anthing ending in ".php".

Re: How to work around FORM method="post" changing "." to "_" please?

I also trying to get my hear around:

http://www.attackers-r-us.com/nastycode

This translates to http://www.attackers-r-us.com/nastycode.php and
with allow_url_fopen enabled, this remote file will be included into
the script and executed. Note that the remote server would have to
serve php files as the raw script, instead of processing them with a
PHP module first, in order for this attack to be effective, or a
script would have to output PHP code ( readfile(realnastycode.php) for
instance).

Mechanisms such as the above allow attackers to execute any code they
desire on vulnerable web systems.

One simple way to prevent this style of attack is to disable
allow_url_fopen. This can be set in php.ini.

Re: OT: security

On Sun, 14 Oct 2007 19:57:59 +0200, wrote:

> I also trying to get my hear around:
>
> http://www.attackers-r-us.com/nastycode
>
> This translates to http://www.attackers-r-us.com/nastycode.php and
> with allow_url_fopen enabled, this remote file will be included into
> the script and executed. Note that the remote server would have to
> serve php files as the raw script, instead of processing them with a
> PHP module first, in order for this attack to be effective, or a
> script would have to output PHP code ( readfile(realnastycode.php) for
> instance).
>
> Mechanisms such as the above allow attackers to execute any code they
> desire on vulnerable web systems.
>
> One simple way to prevent this style of attack is to disable
> allow_url_fopen. This can be set in php.ini.

The last part is totally over the top. And it is of no concern to you: it
would only be a risk if you can have code that includes that code
somewhere on your server, which is what must and can be prevented in the
first place.

You have to consider what kind of files you want to allow (for instance,
only images would easily be checked wether or not getimagesize()) can make
sense of it as an image. Preferably you can validate the types of file you
want to allow.

Somewhat less reliable but OK for starters: find out what kind of
file-extentions can be executed on your system (.php, .php3, .php4, .php5,
..inc, .pl, etc...), and disallow files with that extention to stored.
Having some evil code in randomfile.blup won't matter as it will never be
recognized by the webserver as such, so it won't be executed.
--
Rik Wasmus

Re: OT: security

Great I will do that.. will edit my htaccess file. Thanks for not
taking over my pc by the way. I was pretty silly not to think about
php files!

Re: OT: security

..oO(william.hooper@gmail.com)

>Great I will do that.. will edit my htaccess file. Thanks for not
>taking over my pc by the way. I was pretty silly not to think about
>php files!

Your scripts are still insecure and widely open the door to the entire
server! You should take the scripts down until you know how to write
such things in a secure manner!

Your blacklist approach by disallowing .php files to be uploaded doesn't
work. Dependent on the server configuration there are some more ways to
make it interpret a file as PHP, you can't catch them all. I was still
able to upload and execute my own script, which would have allowed me
not only to read, but to modifiy or even delete any file on the whole
server that PHP has write access to! The only thing I actually did
remove was that script, but you can still find the name I used in the
server's logfiles.

Your main problem is that you allow the upload of any arbitrary files
and let the users download them directly. This is extremely dangerous,
because it's not your script, but the webserver who finally delivers the
files! And the server might have its own opinion about how to handle the
requested file, because that's his job: "A PHP file? Let's execute it."

There are two possible solutions:

1) Use a whitelist approach, i.e. block everything but some file types
you explicitly allow. You still have to check that the uploaded files
are really what they claim to be by inspecting the content, not only by
looking at the file extension. That's quite easy for images (PHP already
has functions for that), but can be a bit more difficult for other file
types.

The better way:

2) Don't let users download the files directly. Store them outside the
document root and use a download script that delivers the files back.
For known types you should send the correct Content-Type header back
(for example 'image/jpeg' for JPEG images), some files maybe as plain
text ('text/plain'), anything else as 'application/octet-stream'. Now
it's not the server's responsibility anymore to handle the requested
file, but it's always your script, which pretty much prevents code
injection (at least at this point - there might be other big holes in
your scripts).

Micha

Re: OT: security

> .oO(william.hooper@gmail.com)
>
> >Great I will do that.. will edit my htaccess file. Thanks for not
> >taking over my pc by the way. I was pretty silly not to think about
> >php files!
>
> Your scripts are still insecure and widely open the door to the entire
> server! You should take the scripts down until you know how to write
> such things in a secure manner!
>

Bank websites and various other e-websites get hacked - so what chance
does the average joe have .


--
www.vhit.co.uk
www.jpgimage.co.uk
www.phpwhois.co.uk
www.cannabiswindow.co.uk

Re: OT: security

..oO(Krustov)

>
>
>> Your scripts are still insecure and widely open the door to the entire
>> server! You should take the scripts down until you know how to write
>> such things in a secure manner!
>
>Bank websites and various other e-websites get hacked

It's still a difference if you have to hack into a server or if can just
walk in with an invitation like in this case.

>so what chance
>does the average joe have .

If Joe doesn't know how to write secure scripts or how to run a server,
then he should ask one that does, unless he wants his server turned into
an open spam relay or even worse things.

Micha

Re: OT: security

..oO(Umberto Salsi)

>Remarks: always save the MIME type as provided by the client, never rely on
>the "extension"

IMHO this might expose new security holes. The MIME type sent from the
client (if it is there at all!) is as unreliable as the file extension,
anything can be faked. If someone uploads some malicious content (maybe
an IE exploit) for example as 'image/jpeg' with a .jpg extension and
your script delivers this file in the same way - well, we all know how
IE deals with file extensions and content type headers ...

>, there are much more MIME types than available three-letters
>readable codes.

There are also libraries available to test/sniff MIME types.

Micha

Re: OT: security

Krustov wrote:
>
>
>
>
>
>> .oO(william.hooper@gmail.com)
>>
>>> Great I will do that.. will edit my htaccess file. Thanks for not
>>> taking over my pc by the way. I was pretty silly not to think about
>>> php files!
>> Your scripts are still insecure and widely open the door to the entire
>> server! You should take the scripts down until you know how to write
>> such things in a secure manner!
>>
>
> Bank websites and various other e-websites get hacked - so what chance
> does the average joe have .
>
>

Just because they are a bank website doesn't mean programmers can't make
mistakes!


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: OT: security

Michael Fesser wrote:

> There are two possible solutions:
>
> 1) Use a whitelist approach,
[...]
>
> The better way:
>
> 2) Don't let users download the files directly. Store them outside the
> document root [...]

3) Store all the meta-data in the DB (full file name, MIME type, upload date,
user name, description, expiry date, access rights, ...), mark this record
with a primary key PK (a number) and then use this number as file name where
the file gets saved, possibly outside the document root of the WEB server.

Remarks: always save the MIME type as provided by the client, never rely on
the "extension", there are much more MIME types than available three-letters
readable codes. Moreover, correctly handling MIME types automatically
makes your application suitable to handle any type of content, past,
present and future.

Best regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it

Re: OT: security

Umberto Salsi wrote:
> Michael Fesser wrote:
>
>> .oO(Umberto Salsi)
>>
>>> Remarks: always save the MIME type as provided by the client, never rely on
>>> the "extension"
>> IMHO this might expose new security holes. The MIME type sent from the
>> client (if it is there at all!) is as unreliable as the file extension,
>> anything can be faked. If someone uploads some malicious content (maybe
>> an IE exploit) for example as 'image/jpeg' with a .jpg extension and
>> your script delivers this file in the same way - well, we all know how
>> IE deals with file extensions and content type headers ...
>
> The file "virus.exe" of type "image/jpeg" definitively *is* an image. That
> seeming extension ".exe" indicates an executable only on Windows, but it
> has no particular meaning on other systems and it must be considered simply
> a descriptive appendix of the file name without any particular meaning.
>

How do you know it is an image without verifying it? And what does the
operating system have to do with it? .jpg is used on both Linux and
Windows, for instance.

> The security of the files, their name and type is not a concern of the WEB
> server. The server has only the responsibility to ensure the respect of the
> Internet standards. Internet standards state that the type of a content
> is uniquely specified by a suitable MIME type. The name of the file may
> contain an extension or something that may look similar to an extension,
> but still this name is only a descriptive text that suggest to the client
> a possible name.
>

It should be. People are used to certain extensions, in all OS's. And
if you're any good webmaster at all, you'll take that into consideration.

> If the client file system needs extensions, it is completely under its
> responsibility to ensure a proper name and a proper extension. So our
> "virus.exe" should be translated to "virus.exe.jpg" or "virus_exe.jpg"
> or something alike.
>

But a webmaster builds a site for the users, and a good webmaster takes
users into consideration.

> If you are going to save the file just uploaded into the file system of
> the server, it is completely under the responsibility of your application
> to build a file name and possibly an extension that fit the conventions of
> the underlying file system. Otherwise if you are going to save the meta-data
> into the DB (name and MIME type) you should simply preserve the original
> name and MIME type, whichever the extension may be.
>

Or the conventions of the users. If it's a Windows executable that's
being uploaded, for instance, it should have a .exe extension.

> People using MSIE usually are completely unaware of what they are doing,
> and spend their time downloading many files, and opening many untrusted
> email every day, blindly executing every type of content. So there is very
> little you can do from your WEB site to protect them.
>

That is an overly broad and inaccurate statement. Webmasters who make
such statements do not understand their users and don't know how to
build sites which cater to users.

>>> , there are much more MIME types than available three-letters
>>> readable codes.
>> There are also libraries available to test/sniff MIME types.
>>
>> Micha
>
> These libraries can be useful if you need to convert from the Internet
> name/type representation to some internal name+extension representation.
>
> All IMHO, obviously.
>
> Best regards,
> ___
> /_|_\ Umberto Salsi
> \/_\/ www.icosaedro.it
>
>

The libraries are useful for determining the mime type is correct. You
should not be changing the file name/extension. Rather, if the mime
type is incorrect, you should reject the upload and notify the uploader
as to the reason.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: OT: security

..oO(Umberto Salsi)

>Michael Fesser wrote:
>
>> .oO(Umberto Salsi)
>>
>> >Remarks: always save the MIME type as provided by the client, never rely on
>> >the "extension"
>>
>> IMHO this might expose new security holes. The MIME type sent from the
>> client (if it is there at all!) is as unreliable as the file extension,
>> anything can be faked. If someone uploads some malicious content (maybe
>> an IE exploit) for example as 'image/jpeg' with a .jpg extension and
>> your script delivers this file in the same way - well, we all know how
>> IE deals with file extensions and content type headers ...
>
>The file "virus.exe" of type "image/jpeg" definitively *is* an image.

It could be anything, unless you have a closer look at its content.
That's the only way to ensure that an uploaded file is really what you
expect or what it claims to be. A MIME type info sent from the client is
just as descriptive or decorative as the file's extension.

>The security of the files, their name and type is not a concern of the WEB
>server. The server has only the responsibility to ensure the respect of the
>Internet standards. Internet standards state that the type of a content
>is uniquely specified by a suitable MIME type.

Yes, but how do you get the _correct_ MIME type for an uploaded file?
The client _may_ send one or not. If there is one, it _may_ be correct
or faked. You can't rely on that.

>If the client file system needs extensions, it is completely under its
>responsibility to ensure a proper name and a proper extension. So our
>"virus.exe" should be translated to "virus.exe.jpg" or "virus_exe.jpg"
>or something alike.

Yes, it _should_. But the world's most used browser doesn't really care
about MIME types and proper handling of received files, that's the
problem.

>People using MSIE usually are completely unaware of what they are doing,
>and spend their time downloading many files, and opening many untrusted
>email every day, blindly executing every type of content. So there is very
>little you can do from your WEB site to protect them.

You can at least make sure that they won't receive malicious files from
your own site.

Micha

Re: OT: security

Michael Fesser wrote:

> .oO(Umberto Salsi)
>
> >Remarks: always save the MIME type as provided by the client, never rely on
> >the "extension"
>
> IMHO this might expose new security holes. The MIME type sent from the
> client (if it is there at all!) is as unreliable as the file extension,
> anything can be faked. If someone uploads some malicious content (maybe
> an IE exploit) for example as 'image/jpeg' with a .jpg extension and
> your script delivers this file in the same way - well, we all know how
> IE deals with file extensions and content type headers ...

The file "virus.exe" of type "image/jpeg" definitively *is* an image. That
seeming extension ".exe" indicates an executable only on Windows, but it
has no particular meaning on other systems and it must be considered simply
a descriptive appendix of the file name without any particular meaning.

The security of the files, their name and type is not a concern of the WEB
server. The server has only the responsibility to ensure the respect of the
Internet standards. Internet standards state that the type of a content
is uniquely specified by a suitable MIME type. The name of the file may
contain an extension or something that may look similar to an extension,
but still this name is only a descriptive text that suggest to the client
a possible name.

If the client file system needs extensions, it is completely under its
responsibility to ensure a proper name and a proper extension. So our
"virus.exe" should be translated to "virus.exe.jpg" or "virus_exe.jpg"
or something alike.

If you are going to save the file just uploaded into the file system of
the server, it is completely under the responsibility of your application
to build a file name and possibly an extension that fit the conventions of
the underlying file system. Otherwise if you are going to save the meta-data
into the DB (name and MIME type) you should simply preserve the original
name and MIME type, whichever the extension may be.

People using MSIE usually are completely unaware of what they are doing,
and spend their time downloading many files, and opening many untrusted
email every day, blindly executing every type of content. So there is very
little you can do from your WEB site to protect them.

> >, there are much more MIME types than available three-letters
> >readable codes.
>
> There are also libraries available to test/sniff MIME types.
>
> Micha

These libraries can be useful if you need to convert from the Internet
name/type representation to some internal name+extension representation.

All IMHO, obviously.

Best regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it

Re: OT: security

Michael Fesser ,

Ok I am really impressed that you managed to edit my pages again even
after I disallowed uploading of ".php*" files. But please tell me a
way to get round it rather than (a) whitelist (b) only allowing types.
Its really depressing not to be able to do this... there must be an
easy trick you used... I am an average joe but this would be a cool
thing...

William

Re: OT: security

..oO(william.hooper@gmail.com)

>Ok I am really impressed that you managed to edit my pages again even
>after I disallowed uploading of ".php*" files. But please tell me a
>way to get round it rather than (a) whitelist (b) only allowing types.
>Its really depressing not to be able to do this... there must be an
>easy trick you used... I am an average joe but this would be a cool
>thing...

I've already posted another possible solution (2.) in
.

If you don't allow direct downloads, but store all uploaded files in a
safe place outside the server's document root and deliver them with a
script, the web server can't execute any of them, which is the reason
for your current problem.

Micha

Re: OT: security

Yes thats a possibility but this is not a bank web site or a pal pal
site. Please just tell me how you broke in... I thought by disabling
files with ".php*" at the end the server would not have run php
scripts but you have found another way. Please just help me out even
though you object to the approach in principle. I have been reading
about it but have not found the answer and meantime my site is down.

Re: OT: security

..oO(william.hooper@gmail.com)

>Yes thats a possibility but this is not a bank web site or a pal pal
>site. Please just tell me how you broke in... I thought by disabling
>files with ".php*" at the end the server would not have run php
>scripts but you have found another way. Please just help me out even
>though you object to the approach in principle. I have been reading
>about it but have not found the answer and meantime my site is down.

I'll try.

It's something in the server configuration. An Apache server can be
configured for a feature called content negotiation (CN). This means the
same resource (a page for example or an image) can be stored in
different versions with different or even multiple file extensions. Then
the server is able to automatically select the most appropriate one to
answer a request.

A simple example - consider these pages:

/foo.html.de
/foo.html.en
/foo.html.es

They are all the same document, but in different languages. If CN is
enabled and someone requests , the server
has three choices and will automatically select the one that matches the
user's preferred language (a bit simplified, but more or less it's like
that).

That's the mechanism, but the really important point here is that the
files on the server can have multiple file extensions. With CN enabled
not all of them have to be passed in the URL when requesting the file -
the server can still search and find them even if you omit some of the
extensions! And that's all I did to bypass your upload restriction. Your
script was checking for a '.php' extension. I just had to add another
arbitrary extension to it (e.g. '.php.42') and the upload worked again.
Because of the CN is was also able to execute the script.

I didn't actually check the configuration of your server (because I
didn't find it where I expected it to be ;-), so I'm not sure if it's
really just the enabled CN on your machine, but it looks like.

The keyword to search for in the server configuration is "MultiViews"
(which is usually not enabled by default). You could also try to add
this to a .htaccess file to disable CN for the site or a directory:

Options -MultiViews

Then try if you're still able to create a file 'phpinfo.php.42' for
example and request it with just 'phpinfo.php'.

Micha