By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,070 Members | 1,238 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,070 IT Pros & Developers. It's quick & easy.

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

P: n/a
here is my form:

<html>
<head></head>
<body>

<FORM ACTION="code.php" method="post">
<INPUT TYPE=SUBMIT NAME="arty.jpg" VALUE="Action">
</FORM>

</body>
</html>

here is code.php:

<?php
if(!empty($_POST)){
foreach($_POST as $myFile =$value){
echo "$myFile";
}
}
?>

What I was expecting is that the code would print out "arty.jpg" when
you click the button.

Instead it prints out "arty_jpg"

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

But I need to pass the filename which may include both "_" and "."
character.

I guess I need some kind of escape and unescape funtion.

Please can someone reccomend one.

PS I am working on a file upload / downalod / delete form at this
link:

http://willyhoops.com/upload/

Many Thanks...

Oct 14 '07 #1
Share this Question
Share on Google+
25 Replies


P: n/a
In our last episode, <11*********************@k35g2000prh.googlegroups. com>,
the lovely and talented wi************@gmail.com broadcast on comp.lang.php:
So the Post method is changing "." to "_"
RTFM. Chapter 65. Question 2.
--
Lars Eighner <http://larseighner.com/ <http://myspace.com/larseighner>
Countdown: 464 days to go.
What do you do when you're debranded?
Oct 14 '07 #2

P: n/a
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.

Oct 14 '07 #3

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

Oct 14 '07 #4

P: n/a
On Sun, 14 Oct 2007 16:54:50 +0200, Lars Eighner <us****@larseighner.com>
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
Oct 14 '07 #5

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

Oct 14 '07 #6

P: n/a
Oh I used "option3: use a different <FORMfor 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!

Oct 14 '07 #7

P: n/a
On Sun, 14 Oct 2007 18:28:58 +0200, <wi************@gmail.comwrote:
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
Oct 14 '07 #8

P: n/a
oh dear... i better fix that one

Oct 14 '07 #9

P: n/a
On Sun, 14 Oct 2007 18:36:19 +0200, Rik Wasmus
<lu************@hotmail.comwrote:
On Sun, 14 Oct 2007 18:28:58 +0200, <wi************@gmail.comwrote:
>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
Oct 14 '07 #10

P: n/a
Oh got thats quite funny but a bit scary!
I am a fool

Oct 14 '07 #11

P: n/a
On Sun, 14 Oct 2007 18:59:14 +0200, <wi************@gmail.comwrote:
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
Oct 14 '07 #12

P: n/a
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!!!

Oct 14 '07 #13

P: n/a
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!

Oct 14 '07 #14

P: n/a
On Sun, 14 Oct 2007 19:03:52 +0200, <wi************@gmail.comwrote:
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
Oct 14 '07 #15

P: n/a
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".

Oct 14 '07 #16

P: n/a
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!

Oct 14 '07 #17

P: n/a
<comp.lang.php>
<Michael Fesser>
<Mon, 15 Oct 2007 18:12:32 +0200>
<h9********************************@4ax.com>
.oO(wi************@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
Oct 15 '07 #18

P: n/a
..oO(Krustov)
><Michael Fesser>
>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
Oct 15 '07 #19

P: n/a
..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
Oct 15 '07 #20

P: n/a
Krustov wrote:
<comp.lang.php>
<Michael Fesser>
<Mon, 15 Oct 2007 18:12:32 +0200>
<h9********************************@4ax.com>
>.oO(wi************@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.
js*******@attglobal.net
==================

Oct 15 '07 #21

P: n/a
Michael Fesser <ne*****@gmx.dewrote:
.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

Oct 16 '07 #22

P: n/a
Umberto Salsi wrote:
Michael Fesser <ne*****@gmx.dewrote:
>.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.
js*******@attglobal.net
==================

Oct 16 '07 #23

P: n/a
..oO(Umberto Salsi)
>Michael Fesser <ne*****@gmx.dewrote:
>.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
Oct 16 '07 #24

P: n/a
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

Oct 30 '07 #25

P: n/a
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.

Nov 4 '07 #26

This discussion thread is closed

Replies have been disabled for this discussion.