Iptanus File Upload Security – A Comprehensive Study

This article sets out, in detail, what Iptanus File Upload does about security: first the threats an upload form exposes a site to, then the plugin’s answer to each of them.

WordPress is by a wide margin the most used CMS, and millions of sites run on it. That makes it a standing target, and it is why anyone running one has to take precautions.

An upload form is one of the riskier things you can put on a site. Built carelessly, it lets an attacker put files of their choosing onto your server, take control of it, or simply overwhelm it. Six threats matter here: arbitrary file uploads, web shells, XSS, CSRF, spam and bot uploads, and denial-of-service attacks.

The threats

Arbitrary file uploads

An unrestricted file upload is a form that will accept any kind of file at all. It is a serious risk, because scripts and executables — .php, .exe and their like — can then be run remotely to explore the file system, extract data, or do damage.

The simplest defence is to check the extension or MIME type and admit only what is on a list you approve. That alone is not enough: attackers use double extensions such as filename.php.jpg, or hide executable code inside apparently harmless files like .svg or .jpeg images. Catching those needs a check for double extensions, and ultimately an inspection of the file’s actual contents.

Web shells

A web shell gives an attacker a way to run arbitrary commands on your server — the equivalent of a terminal on Linux or a command prompt on Windows. To install one, they first have to get a script onto the site through an unrestricted upload; after that, commands go in through ordinary GET or POST requests. Refuse scripts and executables and the whole approach fails at the first step.

Cross-site scripting (XSS)

There are other ways to get code to run. In a typical XSS attack, the code arrives as a parameter on an ordinary request — http://www.mysite.com/?search=<script%20type='text/javascript'>alert(1);</script>. If the site executes it, the attacker can go on to send more elaborate commands, read sensitive information such as cookies, or run things on the server. With an upload form the code can come in through a form parameter, or even through the name of the uploaded file. The defence is sanitising every parameter on the way in and on the way out, and rejecting anything that looks wrong.

Cross-site request forgery (CSRF)

A CSRF attack makes a legitimate, signed-in user perform an action they never intended, without their noticing. Because it is the user who makes the request, it cannot be used to steal data — but it can be used to change something: delete files, alter a password. The site accepts the request precisely because it comes from someone entitled to make it.

An upload plugin is exposed on two fronts, since it handles uploads and also gives administrators a back end for viewing, deleting, editing and downloading. Two defences work: use GET requests only for fetching things, never for changing them, and replace the meaningful parameters of a request with tokens that expire almost immediately and work only once. Replay such a request and it is refused, because the token is already spent.

Spam and bot uploads

A script can hammer an upload form automatically, piling up junk files that consume disk space and bandwidth. The usual answer is a captcha, to establish that there is a person on the other end. Some bots are good enough to solve simple captchas, so the quality of the captcha matters.

Denial-of-service attacks

A denial-of-service attack uses the upload form to exhaust the server — thousands of small files, or a few enormous ones — consuming disk, memory or processing power until the site behaves unpredictably. In the least bad case the server simply stops until it recovers; in the worst, the database or the file system gives way and data is lost. Captchas help, as does watching how often uploads arrive and refusing them past a sensible rate.

How the plugin answers each one

After more than a decade of continuous development, hard use by demanding customers, and regular consultation and audit by security specialists, Iptanus File Upload is built so that installing it does not add to a site’s exposure.

Against arbitrary file uploads

We went through thousands of file extensions and produced two lists: 2,504 extensions treated as dangerous (the blacklist) and 134 common ones treated as acceptable (the whitelist). Nothing on the blacklist is ever accepted, and double extensions are detected and checked.

You can define your own list of permitted extensions through the uploadpatterns attribute, and a short, specific list is strongly recommended. Where no list is given, or the one given is too broad, the plugin falls back on its own whitelist. On top of that, every uploaded file goes through:

• detection of its real MIME type from its contents;
• validation of image files, to establish whether they are images at all;
• heuristic analysis of text files, looking for executable code.

Against web shells

A web shell needs a script file on the server, so stopping arbitrary uploads stops web shells. There remains the possibility that code is hidden inside a file with a legitimate extension and slips past the filters. Such a file is harmless while its extension stays as it is — it only becomes dangerous if someone can rename it to something executable. The plugin lets administrators rename files but not change their extension, so that route is closed too.

Against XSS

Every request the plugin handles is inspected on several levels before anything is done with it. The handler knows which parameters and which caller to expect; a request from the wrong caller, or missing a parameter, is rejected outright. Parameters are strictly sanitised according to their type, and a value that fails sanitisation takes the request down with it. WordPress nonces are used throughout to verify the referrer and the request itself.

Against CSRF

The plugin has a substantial back end — changing settings, browsing, editing, deleting and downloading files, viewing upload history, running maintenance — and every one of those is served by a request. Any request that changes something hides its parameters behind unique tokens. A request to delete a file carries no file path and no file ID; it carries a token that lives briefly and works once. An attacker cannot construct such a request without the token, and cannot replay one because the token has expired.

The plugin also never exposes sensitive data — settings, URLs, filenames — in a request URL or a response; tokens stand in for all of it. And every variable that reaches the HTML of an upload form, a file viewer or a Dashboard page is escaped, so there is no opening for injected JavaScript.

Against spam and bot uploads

You can put a captcha on any upload form. The plugin uses Google reCAPTCHA, among the most robust options available, and supports it with or without keys of your own.

Against denial-of-service

Beyond the captcha, the plugin watches how often uploads arrive. A large number in a short window is treated as an attack: further uploads are refused and the administrator is notified by email. The other shape of the attack — a handful of enormous files, aimed at filling the disk — is caught by the file size filter: anything above the limit set by the maxsize attribute is rejected before it is uploaded at all.

Audits and updates

The plugin is audited about every six months by independent security specialists, and by wordpress.org and Wordfence.

None of this is ever finished. Attackers find new ways in, and a plugin has to keep up. We release updates regularly, and an urgent one whenever a weakness or a serious bug comes to light.

For more about the plugin’s security, please contact us.

The Iptanus team