3

We have to implement a user profile image upload feature in our web application. The user can upload his profile image.

After uploading the image, it will be saved to a DB2 DB, and it will be rendered only to the user who uploaded the image after the login.

Technology stack is J2EE, AIX, DB2.

We received a strange complaint from our security department that this feature needs to be dropped because the user may upload a virus and this will infect the server!

I don't understand how a user will upload the virus. At the end of the day, the virus is a program that needs to be executed, right?

Second thing: the platform is UNIX-AIX. Even if a user uploaded a malware the server will not be infected, right?

Last thing: there is a possibility that the user would be infected by XSS in the case where a JS file was uploaded instead of image. But, I can see that in our case this is not valid because only the user can upload the image and it will be rendered only to the user.

Is my understanding is right?

2 Answers 2

5

As schroeder mentioned, you may have neglected some detail here, which makes your security group nervous.

There are a number of classes of attack the security group may be concerned with. Just a few for example that might be worrying them:

  • File Upload - you don't mention how this is handled. Some questions to consider - Is there enough temp space on disk, what happens to the temp file after the upload, can the user specify the file name, how is the file size determined and enforced? Any and all of these could be vectors for an attacker. The most obvious one would be to tell the server the file is one size, have the server allocate that much memory, then send something bigger and corrupt the server's memory, possibly getting code execution.
  • Store in the database - can the user specify a file name, or is their username added to the database table, and if so, what does the SQL to store those values look like? Are you sanitizing the input, or using stored procedures, or does you code do something like (pseudo-code) "db.store($picture_file, $name, $table_users)" ? In the latter case, that's very bad, and likely to expose you to SQL injection . Not strictly speaking a "virus" but something your security department would care about.
  • Upload authorization - Could someone else upload a file on behalf of a different user (e.g. could they guess a user number in a URL parameter)? Or, you mention XSS. What if the user is victimized by some other site via XSS to upload a payload to your site?
  • AIX OS resistance - No OS or specific flavor of Unix is 100% safe. Assume the attacker is out to get you (or your user) and has done their homework and has crafted AIX-specific shell code.

Basically, what it comes down to is that we don't have enough details for a thorough security audit of the feature, but your security team does. The details matter and the list of the technology stack provided tells us nothing about the vulnerability profile of your specific application.

One can make a reasonably secure "image file upload" function for a service, but nothing in your initial post suggests excessive paranoia on the part of your security group.

Talk to them, find out specifically what they don't like about the feature, and work with them to provide the functionality you want in a way acceptable to them.

1
  • To expand the input validation part: Are you checking that the image can be loaded as the image format it claims to be? Does the security team any you to employ a virus scan on every file uploaded?
    – Ztyx
    Commented Apr 19, 2016 at 6:24
1

First: you are correct that the image would need to be processed, and that the server should only store and supply the file to the client requesting it to render (it is typically not the server that renders it). But, I do not know how your system handles uploads.

Second: what if your server does process uploaded images, and someone uploads a AIX virus? No OS is perfectly resistant to malware.

Lastly: If your system does what it is supposed to do, then, yes, a JS script would only affect the user account that uploaded it. The assumption here is that it is the same user viewing the image as the one uploading it. Consider a compromised account: an attacker could upload a JS script and get even deeper access to the valid user's machine. This might be solved easily by inspecting the headers of the uploaded files to ensure that it is an image and not a script.

From the few details you provide, I agree that it is a strange complaint from your security folks, but you might have left out an important detail, and not all security professionals are perfect. You are doing the right thing by asking, but don't forget to raise these questions with them directly.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .