New answers tagged

3

Are you using Microsoft Windows? If so, yes, it's possible, but... Let's say you connect your iPhone to your computer. If you view the photos on your iPhone in Windows Explorer, then you will have thumbnail remnants for all viewed images. These remnants are stored in C:\Users\username\AppData\Local\Microsoft\Windows\Explorer\ as thumbcache*.db And yes, ...


1

Could they see the content of the files? Likely no. But anti-virus software is typically configured to scan files when media is connected, so it is possible that the system inventoried the files and file names.


-1

No not with default setup. Only photos being uploaded are visible on your PC. That's the whole point of uploading. The only things you need to be careful about are those cloud-services who synchronize your pictures, or who somehow have sketchy services like "View recent photos uploaded", or "View files on device X from Y",...


0

Just a thought - while not really hacking the server, being able to upload a jpg file with embedded self executing js from the exif, which can then cause mayhem on the client machine, would certainly be a security issue from the user's perspective. see: http://blog.trendmicro.com/trendlabs-security-intelligence/jpeg-files-used-for-targeted-attack-malware/


2

I suggest a short-term quarantine of all uploaded files. You can use local systems scanning and AV tools in a temporary jail. This way you could add a routine to scan for malicious files and ignore all the different names of files. This stops the whack-a-mole game. This would add some latency to the application. I know this is not a coding solution but it ...


12

Don't block any specific MIME types. Block any kind of execution of the uploaded files. A simple way is to store uploaded files outside of the web root and serve them via scripting. If that's not possible, store files in a subdirectory and configure your server not to execute any scripts in that directory. Remember to do this for any scripting language that ...


2

Yes, that is very dangerous. Because the attacker is able to place a file directly on the disk simply viewing directory contents can infect the machine. For example: I assume that computer syncing with dropbox is running Windows. Windows shows preview Images for all files (e.g. Word documents, text files, images, ...). Those are generated based on the ...


5

Are there any other filetype that I also should block? It doesn't matter, as finfo_file can be bypassed, see for example here: Encoding Web Shells in PNG IDAT chunks. mime_content_type doesn't seem to be more reliable either. You need to check for file extension in addition to the mimetype check, as it is a lot more reliable, as file names are a lot ...


20

It is not clear from your description why you want block these files exactly. I see the following possibilities: You want to block files that might infect the server itself. Unfortunately this can be about anything: shell, perl, python, awk, ... and of course compiled binaries. But to get these files executed without explicitly calling them with an ...


5

Regardless of the placement of the PHP code [...], the website just shows the image file when I open it after uploading Yes, that is how it should be. The server would be seriously vulnerable if it would interpret .jpg files as .php files depending on the content instead of the extension. So in such a case, what should be done to execute the file ...


2

I assume you want to know if there is a way to execute the uploaded PHP file. Short Answer: No Long Anwser: As long as the web server is configured correctly only .php files gets executed as PHP. Most web servers will return as content type always the mime type derived from the file extension. The content itself of the HTTP response is typically the content ...


1

Don't upload the private key to the server. Instead, send the encrypted shared key to the user. The user can then decrypt with the private key, which stays on the user's system. Then, the user sends the decrypted shared key to the server.


1

For part two, you can do sensibly better: (The session between User and System is encrypted) User starts a task that requires an encrypted file System sends tne encrypted shared key User locally decrypts the shared key User sends the decrypted shared key (stays only in memory) System decrypts the file into memory System deletes the decrypted shared key ...



Top 50 recent answers are included