Forum Moderators: coopster
There are of course many gallery type thumbnail scripts, but it's been nearly impossible to find one that will do the following after the user arrives at the script's online form page:
-- first they give the html page a unique name, ie, vacation.html
-- they next type in some text describing the photo that will be seen at vacation.html
-- then they navigate to the photo on their harddrive via a "Browse" button
-- click submit ==> the photo is uploaded and a page is generated called vacation.html with some text and the picture.
Ideally such a script would have a config file that would allow the site owner to identify exactly which folder the images will go into; which folder will hold the html pages; the images could be of varying dimensions however a limit could be put on the maximum file size of each photo (for ex, 1 MB); only .jpg, .png, or .gif files would be allowed; and an option could be selected as to whether to permit overwrites.
If anyone has seen anything like this, I'd very much appreciate the reference... thanks for any feedback...
[webmasterworld.com...]
Unfortunately, it would need modification as well. It may be difficult to find one that does exactly what you want.
Have you searched hotscripts.com?
Birdman
All I was hoping to find is a script that would write the name of a single image file (as identified by the user) to an html page (also identified by the user), along with a text description (as your script does). It would not even be necessary to write the img src's width and height, as the browser would still display the photo fine without that information. Probably wouldn't need MySQL either.
Re Hotscripts -- that is usually my first or second resource to check, so yes I spent a LOT of time there yesterday. Luckily they were not charging by the minute!
You run some security risks using this method. If the script is going to create an HTML file with the user-specified image, that means that the process that runs the script (the web server) will own that HTML file and have full rights to it. That means that anyone anywhere can overwrite that file via an HTTP upload, your web server will let them do it.
In other words, someone can create vacation.html, and someone else can just as easily come by and destroy it.
There are ways to make this option more secure (i.e. having the file created in another directory, and then have a cron job owned by another user on the system (not the web server) move the file to its final destination, but there really is a better way to do this.
My recommendation would be to use a database on the backend. Instead of creating a brand new HTML file, the process simply adds a row to the database, and you'd have a script that would access this database instead of individual HTML files. This also gives you more flexibility in the future if you happen to redesign the site (edit one file instead of many).
I use templates in a couple different manners.
1. a single file and put placeholder values into the file
imgtemp.html
<html>
<head>
<title><!--MYTITLE--></title>
</head>
<body>
<p><img src="<!--IMGPATH-->" border="0">
<p><!--DESCRIPTION-->
</body>
</html>
then you could use str_replace to put the values into your template and save it as vacation.html
2. have your template saved in chunks
imgtemp1.html
<html>
<head>
<title>
imgtemp2.html
</title>
</head>
<body>
<p><img src="
imgtemp3.html
" border="0">
<p>
imgtemp4.html
</body>
</html>
you can then put each chunk into a var and cat your values in between and then save the whole as vacation.html
<I was hoping that if the config file had a variable that either did ( = 1) or did not ( = 0) allow overwrite, then that would secure our example "vacation.html".>
The security vulnerability in this scenario that I'm referring to actually has nothing to do with your script. What I mean is that I could create a file (with anything I wanted in it) on my own system called vacation.html. Then I could use my browser to upload it, completely independent of your script or anything else on your site, and your web-server would accept it and overwrite the existing vacation.html file.
The reason for this is because vacation.html would be created by your web-server, which means that your web-server would have write access to the file, and your web-server process is world-accessible. Does that make sense?
There are a LOT of perl and php "upload" scripts in the various archives, so my question is....
Will most of them be vulnerable in the manner you describe? (unless they reference a database, as in your first suggestion)
Or was it simply my "ideal script" that was flawed, in that I allowed the user to name the file however they wanted prior to upload?
In other words, if my "ideal script" were to actually name each uploaded html file itself, then does that work-around the security concern? (for example, it assigns sequentially numbered names such as: "upload1.html" ; upload2.html" etc, which are never repeated)
Thanks you too jatar_k for your suggestion -- but will that work given what Nick has pointed out?
<There are a LOT of perl and php "upload" scripts in the various archives, so my question is....
Will most of them be vulnerable in the manner you describe? (unless they reference a database, as in your first suggestion)
Or was it simply my "ideal script" that was flawed, in that I allowed the user to name the file however they wanted prior to upload?>
The problem isn't that people are naming the files themselves, because the name can be gathered from the URL, and someone can use that to overwrite the files with their own content.
I haven't used these pre-made scripts before, so I can't speak for them. But I would say that to use this method, your best bet would be to create a folder outside of your publically-accessible space (an area on that server that cannot be reached by [yourdomain),...] yet it is owned by the user that runs the web-server process. Have the files uploaded here, and then have a script running on the server, that is owned by the same user that you use to upload content to the site, and have it copy the file into a publically-accessible space.
First, it will mean that no one can overwrite the file that someone else has uploaded because they can't access it with a URL; and even if they could it wouldn't matter because you're not using that file anymore once you've made a copy of it. Second, the file that is publically-accessible will be owned by you, the same user that is used to upload all of your other content to the server.
The method of doing this depends on how much access you have to the server. You could run a cron job, and this happens hourly, so there is a slight delay. You could also have something like this in your script:
exec("sudo -u myuser cp /home/mysite/uploads/$UploadedFile /home/mysite/public_html/publically-accessible");
This would cause "myuser" (replace with your username here) to run the above command, which means that the destination file will be owned by "myuser." The above command won't work as-is because you'll need a password. This opens up other security holes as well since this would mean that the web-server would have the ability to do things as other users (and possibly root).
I think a cron job would be the safest, as anything tied directly to your script would probably mean that the web-server would have access to things that you wouldn't want it to be able to do.
"...your best bet would be to create a folder outside of your publically-accessible space (an area on that server that cannot be reached by [yourdomain),...] yet it is owned by the user that runs the web-server process..."
Would an example of this be a subfolder within cgi-bin that has permissions of 744 (or 755)?
Or, are you referring to a new folder that would reside one level higher than public_html? If so, I honestly don't know if the server allows any activity at that level (have never tried)...
<Would an example of this be a subfolder within cgi-bin that has permissions of 744 (or 755)?>
No, because this can still be accessed via URL.
<Or, are you referring to a new folder that would reside one level higher than public_html? If so, I honestly don't know if the server allows any activity at that level (have never tried)...>
Close.. I'm actually referring to a directory (folder) on the same level as public_html. For instance, when I access:
http*//www.yourdomain.com
I'm actually accessing a particular folder on your server, like:
/home/mysite/public_html
In this case, create:
/home/mysite/uploads
Because this directory can't be access by a URL, but the web-server can have write access to it.
The trick is copying the file into a directory that can be accessed by a URL (so people can view it) but in a way that you own the file, not the user running the web-server process. If the user running the web-server process owns the file, then anyone in the world can overwrite it.
