Re^7: issues displaying cgi script source?

[antirice]

Alas, there's the rub. You're offering this script for download as well. While it may not work for your machine, it may work elsewhere. Thus I have to say it: fix your damn code!

How do you extract only the file? Glad you asked:

use File::Spec;

my $file = "../this/is/a/problem/file.pl";
$file = (File::Spec->splitpath($file))[2] if $file;
print $file;
__END__
file.pl

[Elijah]

I think you are a bit confused.

The script you are talking about writes to the harddisk and does not read from it so "extracting the file" as you put it in your example is irrelevant. Furthermore both scripts have been fixed for two days now. Lastly I already tried to implement File::Spec two days ago. While I did not use splitpath I did try no_upwards() and this was not feasible for my usage.

The no_upwards method and your method (if it was applied to writing and not reading) both require the script to be able to write to the cgi-bin folder. Now I know you surely cannot be suggesting that! That would be the largest security hole I have heard of to date on this topic. The very nature of the script is it has to run in cgi-bin and write to a directory outside of cgi-bin.

You're offering this script for download as well.

Again you are mistaken, if you are going to give advice make sure you have your facts straight first. I still am not positive what script you are talking about since your first post referenced a script that wrote to the filesystem and you tried to point out a security hole that did not exist in that script and now this post tries to tell me how to fix a read hole in another script that has been fixed for 2 days?

While it may not work for your machine, it may work elsewhere.

The permissions on my machine are default therefore if it were to work on anyone elses machine they would purposely have to change the permission setting to allow all users on the system to be able to write to their home directory. If they did that then they deserve to be taken advantage of.

As I say the security hole you talked about does not exist but I made it more strict anyway.

[antirice]

I am talking about your code Elijah! Stop taking this personally!

I was speaking of your submit script. I see that you've changed it as you now check whether or not it contains "..". However, note that "blah..pl" most certainly is a legal filename.

What do I mean by extracting the file? I mean remove the file portion of a path. That's it. I apologize for being ambiguous. Check out the documentation and notice that File::Spec->splitpath() returns a list containing three elements, the last of which is the filename. That's what I wanted you to grab, the third element of the list which is the part that contains a legal filename.

both require the script to be able to write to the cgi-bin folder

Do you understand what it means when I say, "While it may not work for your machine, it may work elsewhere?" You fire back with "These are default settings! No one ever changes defaults unless they know what they're doing!" Not necessarily. Some people change permissions on files and directories because they want to create a web interface to upload scripts to their site. Suppose the hosting company setup the account incorrectly? Suppose they accidentally messed up some of the permissions? Suppose they're running a different webserver on a machine where file permissions don't exist? Just because the configuration of your server protects you against a possible exploit in your code DOES NOT mean that you shouldn't protect against it anyway. Understand where I'm going with this? Code responsibly and make your script as secure as possible, especially when you are offering it to the world.

[Elijah]

I am talking about your code Elijah! Stop taking this personally!

You are right I apologize.

Also yes I see now how I could have used splitpath as long as the full fule path was hard coded, which it is, I could grab the third element and append to a hard coded variable.

Some people change permissions on files and directories because they want to create a web interface to upload scripts to their site.

Hmm this sound familiar... LOL

Suppose they're running a different webserver on a machine where file permissions don't exist?

That's blashpeme! Bite your tounge. If they are running a webserver on a machine that has no file permissions (or at least weak ones) then this would mean more than likely they are running Windows IIS and in that case they have a lot more problem to worry about then my stupid script.

I never intended people to download my script and use it. I merely posted it originally to show how I coded it and to give people ideas on snippets of code if they wanted to write something themselves and see how I did it. This does not excuse the fact that it did have an issue, although the /tmp directory was the only other directory I was able to write to that is still a problem I was not aware of and have since fixed. I will more then likely try implementing splitpath() too to see what I like more. I generally do not like to import modules for a simple task if I can find a way to code it myself.

And yes while blah..pl is a very legal file name it would never exist on my system. I do not label files in that manner and again I did not intend on the widespread usage of this script. As I said quiet a few posts back, I am still learning and oversights are still more common than I would like them to be but it is something I am dealing with.