Validating Image Uploads With Javascript & Java -

the site designing allows users upload images (png, jpeg, or gif) servlet within backend. i've accomplished far in terms of security...

1. validate image client side checking files extension. if extension valid send servlet backend validation.
2. validate mime type of image , make sure either image/jpeg, image/gif, or image/png.
3. read first 10 bytes of image, convert them hex, , validate hex matches magic numbers of either png, jpeg or gif. here's example of magic numbers when user uploads png - 89 50 4e 47 0d 0a 1a 0a.

so mime , magic number validation on server side, , extension validation on client side. works great have 2 quick questions...

1. is there purpose send file name servlet check extension server side since i'm checking mime , magic?
2. what else should in terms of security, , change current approach?

and please don't "i don't think it's necessary" security steps because number 1 goal here learn. if there .001% chance site @ risk, i'd still learn best way protect myself. thank you.

validate image client side checking files extension. if extension valid send servlet backend validation.

this may fail non-windows users, filetypes not determined extension on filename.

it can useful add js warning "this file doesn't end in .png/.gif/.jpeg/.jpg - sure image?", it's not idea disallow upload based on extension.

validate mime type of image , make sure either image/jpeg, image/gif, or image/png.

again there problems here. on windows, mime type retrieved registry associations, variable , not correct. example ie commonly sends jpegs image/pjpeg, , citrix users may find uploaded image/x-citrix-pjpeg.

since media type typically unused upload scripts, there's little point reading/checking it. types here, i'd best bet ignore filename , mime type; use magic number sniffing determine format.

what else should in terms of security

1) careful name use store file - taking user's submitted filename verbatim dangerous due directory traversal, special filenames , extensions (.htaccess, .jsp etc), , unreliable because file naming rules can complicated cross-platform.

if want use supplied name on local filesystem @ should basenamed, slugified (replacing whitelist of simple characters), length-limited, , extension replaced/added detected filetype.

better store file generated name (eg 17264.dat file related item primary key 17264 in database); if need serve browsers pretty filename can use rewrites on front-end web server, or file-serving servlet, make visible /images/17264/some_name.png.

2) because has image magic numbers doesn't mean it's image, or if is valid image, doesn't have other content in different form @ same time (a 'chameleon' file).

for example, html-like content in binary file can fool dodgy mime-sniffing in older versions of ie treating html. flash tricked loading <crossdomain> policy set out of xml inside image, , java load applets gifs.

one way of making harder load image using server-side graphics library, , re-save it, causing round of recompression garble parsable content in file. problem lossy compression jpeg, recompressing results in loss of visual quality.

the ultimate solution give , serve image different hostname main site. if attacker manages xss content file, doesn't matter there's nothing on site it's living in compromise, other static images.

3) if load image server-side, (2) or other reasons, ensure image size - both file size , width/height size - reasonable before attempting load it. otherwise can hit decompression bombs filling memory , causing denial of service.

also if make sure keep image library/language (eg java graphics2d) date. there have been image-handling vulnerabilities in these languages before.