Image uploading
Moderator: General Moderators
- andym01480
- Forum Contributor
- Posts: 390
- Joined: Wed Apr 19, 2006 5:01 pm
Image uploading
Assuming htaccess requires valid user etc on an image directory, how safe is an image uploading script in the content section of a web site?
The images would be small and are needed with data stored in a mysql table, so would uploading to a blob field be safer, quicker (running) and easier?
The images would be small and are needed with data stored in a mysql table, so would uploading to a blob field be safer, quicker (running) and easier?
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Use getimagesize() to determine if the image is an actual image, and not some file disguised as one. By just checking the extension of a file someone may be able to inject harmful code or programs onto your server. Other than that, you are pretty safe.Assuming htaccess requires valid user etc on an image directory, how safe is an image uploading script in the content section of a web site?
Quicker? No. There is much overhead when using a database to server images. Use the filesystem designed for this kind of stuff! Simply store the location of the image and server that to a <img> tag or something.The images would be small and are needed with data stored in a mysql table, so would uploading to a blob field be safer, quicker (running) and easier?
Easier? Not really. It's a bit more work to get things running smoothly, but not much of a difference.
Safer? Not really. Safety has not much do to serving the images on your site, you just have to make sure you've checked its an image.
- andym01480
- Forum Contributor
- Posts: 390
- Joined: Wed Apr 19, 2006 5:01 pm
I can only suggest that you write a little script that maintains access rights on your files.. Doing it manually just takes too much time, which is a pita if you regularly extra phpprojects in your pubwww folder and only want to give the required rights and offcourse, there will be a day that you make a mistake anyway...
eg: http://timvw.madoka.be/programming/bash/chmoder.txt
eg: http://timvw.madoka.be/programming/bash/chmoder.txt
- andym01480
- Forum Contributor
- Posts: 390
- Joined: Wed Apr 19, 2006 5:01 pm
A number of follow ups, I am afraid
1) Does 666 on an upload directory mean that unscrupulous people could write to that directory not via my script on the server which is protected by htaccess?
2) If so, how can I protect against it?
3)Is that "Cross site scripting"?
4) timvw - didn't understand your post or script - sorry - what do you mean?
5) Last question what is the difference between read and execute? Is read for html and execute to allow php etc to "run"?
1) Does 666 on an upload directory mean that unscrupulous people could write to that directory not via my script on the server which is protected by htaccess?
2) If so, how can I protect against it?
3)Is that "Cross site scripting"?
4) timvw - didn't understand your post or script - sorry - what do you mean?
5) Last question what is the difference between read and execute? Is read for html and execute to allow php etc to "run"?
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
<Off-topic>R4000 wrote: ect. codes work in the forum, what a security risk
I don't see a risk.... these are entities.... browsers are asked to parse entities, not parse them and then parse the output.
</Off-topic>
~andym01480
1) 666 Does mean that other people could write to that file yes; here's a file in 666:
-rw-rw-rw- 1 d11wtq users 8 2006-04-27 22:29 foo
Try 664 instead, but at the end of the day, the web user needs to have write access to the folder so anybody with access to PHP running under that user id will likely have write access. If your web host uses suexec with CGI then you're OK
2) See above (suexec primarily)
3) No. XSS is mostly used to steal cookies from any users machine by allowing a web page to unknowingly produce vicious code.
4) I'll let timvw answer but I guess it's a Unix/Linux command line tool (I never looked)
5) Read access alows you to open a file and view it's contents. On a directory it allows you to list its contents. Execute access means you can run the file (for example, a command line script (bash script... same as a batch script in dos)). You don't need read access to execute a file.... this is really for applications not text files. On a directory, execute access allows you to use that directory as a working directory (i.e. you can move yourself into it using the cd command). Without execute access on a directory you can't get inside it, but you can list it's contents from the outside if you have read access on it. To be honest, when it comes to directories the whole read/execute thing confuses a lot of people
One way I've gotten around this in the past is to actually ftp from my upload page back into my site and add the file that way.
By doing this you can add images to a folder that does not have write or execute access for the www user. Because you are FTPing back into the site through your site's FTP user then you only need write access for your FTP user.
- Eric
By doing this you can add images to a folder that does not have write or execute access for the www user. Because you are FTPing back into the site through your site's FTP user then you only need write access for your FTP user.
- Eric
My point was, if you try php scripts quite often, you usually download them, and then upload them... Usually their are too much rights on those files when they are unzipped/untarred/uploaded... chmodding them time after time becomes an annoying and repetitive job... So my suggestion was to automate that process (eg: write a script to do it for you)
Basically, i only give myself read-write on files and read-write-execute on directories.
Then i allow the user nobody (in group services) access the path to my pubwww dir (chmod +x )
And then i give that user to +r to my files and +x to my directories in the pubwww dir
And then i give some specific rights to write somewhere in /home/outofpubwww
Yes, it took a little while to figure out which rights apache needed precisely, but as soon as i knew it, i've been able to maintain the rights on a "as-needed" basis.
Basically, i only give myself read-write on files and read-write-execute on directories.
Then i allow the user nobody (in group services) access the path to my pubwww dir (chmod +x )
And then i give that user to +r to my files and +x to my directories in the pubwww dir
And then i give some specific rights to write somewhere in /home/outofpubwww
Yes, it took a little while to figure out which rights apache needed precisely, but as soon as i knew it, i've been able to maintain the rights on a "as-needed" basis.