1. You can upload scripts that get scanned for malicious code
2. These scripts can be executed once deemed "safe"
3. The server is using MD5 hashes to determine if you uploaded the same file or if it should re-scan it
3. Is where the issue is. It should probably always re-scan it and it definitely should not be using MD5.
>The server is using MD5 hashes to determine if you uploaded the same file or if it should re-scan it
Wouldn't the sensible thing for a server that gets an upload matching an existing file's hash be to just treat it as an idempotent no-op? What reason would it have to replace the old version with a presumably identical copy? What am I missing?
I assume the scanner is a separate library/service that receives the contents and returns a boolean safe/malicious result, and the implementation using MD5 to avoid expensive re-scans is an internal detail hidden from the caller.
Secure for now, rather. A solid game plan would be to have your code base set up to easily swap in a new hashing method when called for. I believe Django automatically promotes passwords stored with insecure hashes to secure ones the next time a user logs in.
the safe file is not a valid php file? it might be executed if php is like javascript ignorning valid chars, but i doubt something actually 'looking at it' would accept it as benign or valid.
1. You can upload scripts that get scanned for malicious code 2. These scripts can be executed once deemed "safe" 3. The server is using MD5 hashes to determine if you uploaded the same file or if it should re-scan it
3. Is where the issue is. It should probably always re-scan it and it definitely should not be using MD5.