Well, I knew everything wasn’t that simple. Maybe my date for digging for treasure on the UNSW server will be pushed back (just a joke!)
what is that vulnerability:
A file upload vulnerability is when a user uploads an executable script file and gains the ability to execute server-side commands through this script file. This type of attack is the most direct and effective. There is no problem with the “file upload” itself, the problem is how the server handles and interprets the file after it is uploaded. If the server’s processing logic is not secure enough, it can lead to serious consequences.
Most websites and applications have upload functionality, and some file upload implementations do not strictly limit the file extensions and file types that can be uploaded, allowing an attacker to upload arbitrary PHP files to a web-accessible directory and pass them to the PHP interpreter, which can then execute arbitrary PHP scripts on the process server.
When a file upload vulnerability exists, an attacker can upload viruses, Trojans, WebShell, other malicious scripts, or images containing scripts to the server, and these files will facilitate subsequent attacks. Depending on the specific vulnerability, the scripts uploaded here can be PHP, ASP, and JSP scripts with normal extensions, or scripts with tampered extensions.
why it’s bad:
1. The uploaded file is in a web scripting language, and the server’s web container interprets and executes the user’s uploaded script, resulting in code execution.
2. The uploaded file is a virus or Trojan horse, which is used to trick users or administrators into downloading and executing the file, or running it automatically;
3. The uploaded file is a Flash policy file, crossdomain.xml, which is used by the hacker to control Flash’s behaviour in that domain (other similar ways of controlling policy files are also possible).
4. The uploaded file is a virus or Trojan horse file, which is used by hackers to trick users or administrators to download and execute;
5. The uploaded file is a phishing image or an image containing a script, which can be executed as a script in some versions of browsers and used for phishing and fraud. In addition, there are some uncommon exploitation methods, such as uploading a file as an entry point, overflowing the server’s background processing procedures, such as image parsing module; or uploading a legitimate text file, the contents of which contains a PHP script, and then through the “Local File Include vulnerability (Local File Include)” to execute this script.
How to prevent:
The directory where the file is uploaded is set to be non-executable. As long as the web container is unable to parse files under that directory, the server itself will not be affected even if an attacker uploads a script file, so this is critical.
Determining the file type. A combination of MIME Type, suffix checking, etc. can be used when determining the file type. In the file
file type checking, the whitelist approach is highly recommended, the blacklist approach has been proven to be unreliable countless times. In addition, for image processing, you can use compression function or resize function to destroy the HTML code that may be contained in the image while processing the image.
Rewriting file names and file paths using random numbers. File uploads require the user to be able to access the file if the code is to be executed. In some environments, the user can upload, but not access. If a random number is applied to rewrite the file name and path, it will greatly increase the cost of the attack. Then there are files like shell.php.rar.rar and crossdomain.xml that will be unattackable due to renaming.
Set the domain name of the file server separately. A range of client-side attacks will be invalidated due to the browser homologation policy, such as uploading crossdomain.xml and uploading XSS exploits that contain Javascript will be resolved.
Use security appliances for defence. The essence of file upload attacks is to upload malicious files or scripts to the server. Professional security appliances defend against such vulnerabilities mainly by detecting the uploading of exploits and the uploading process of malicious files. Malicious files come in all shapes and sizes, and there are many new ways to hide them, so for the average system administrator, security appliances can be deployed to help defend against them.
Well, this is simply a living example of security engineers fighting against hackers. Careless engineers develop flawed programmes, then hackers breach the system, then security engineers develop patches, then hackers attack again …… Wait for me UNSW You won this time, but that doesn’t mean you’ll win every time!(just a joke).
今朝有酒今朝醉 