这个客户端应用程序安全吗？

Question

Here is a simplified version of a program I am using to work with a file using javascript on the client side.

HTML:

<input id='myinput' type='file' accept='.png, .jpg, .jpeg' /> 

Javascript:

 var myinput = document.getElementById('myinput');
 myinput.addEventListener('change', function(e) {

   /* 1. capture the file */
   var file = e.target.files[0];

   /* 2. make a fileReader object */
   var reader = new FileReader();

   /* 3. the load event listener */
   reader.addEventListener('load', function(e) {
     var fileContentAsText = e.target.result; // <-- is this line safe?
     /* 5. functions for manipulating the file would go here */
   }, false); 

   /* 4. passing the file to the filereader object */
   reader.readAsText(file);

 });

More or less, my program is for manipulating png or jpg type files, manipulating them, then making the modified version available for download.

Everything happens on the client side.

Since nothing is being sent to the server, are there any security vulnerabilities that I should be concerned about?

If I was sending it to the server, almost everything I would have done to validate the file would have been in php, and I would have been reasonably assured that the operation was secure enough.

Since I am not sending it to the server, none of those php mechanisms I would have applied are applicable.

Actual questions:

1. Given that everything will happen on the client side, do I need to validate the file?
2. If so, why? And what actions can I take?

What comes to mind are text boxes that set the innerHTML of other elements, or where src/onerror attributes can be exploited for nefarious purposes. Are these types of attacks something I need to watch out for? Because everything I have read on this matter concerns validating a file that goes to the server.

Answer 1

You have to be aware of vulnerabilities like for example cross-site scripting, open redirection, sensitive information storage (not a comprehensive list), which may also affect client-only applications.

In practice this means the important part is point 5. in the comments - what happens to the loaded file. For example you could store part of it after processing in say localStorage, which may present a risk if "sensitive" info is stored (be it whatever in your context). Or for example if a part is written back to the client (which I think is the case if I understand correctly), it could pose an injection threat. The most straightforward injection would be XSS if you for example write somehing to html, like the comment from the image exif. But you should also consider what happens to the resulting file after the user receives the result. Will it be displayed in an application that may be vulnerable to some kind of an injection, or for example buffer overflow? Consider an image viewer that has a known buffer overflow vulnerability. Say a malicious user prepares an image and gives it to the victim. This image may be crafted in a way that it does not directly result in buffer overflow, but after the transformations your application does to it, it exploits vulnerabilities in the client that displays it. Sure, it's a vulnerability of the 3rd party client software, but your application was used to hide the exploit and facilitate an attack.

So try to consider the system as a whole, your apllication may just be a building block in a complex attack, and your goal should be to minimize the usefulness for an attacker. This is vague advice, but it all depends on what you actually do to the uploaded file.

Another thing that comes to mind is a malicious uploaded image may hang the browser process, a denial of service on the client. You should be able to avoid this. (Sure, the user uploads it for herself, but may not be aware of what it is she's uploading, having received it from somebody else - may or may not be valid in your scenario.)

Aldo during processing, parts of the image info may be used for say querying things, for example to find the camera vendor from the exif info or whatever. Such queries may also be susceptible to injection, resulting in query forgery via a malicious image. So anything you read from the file during processing should be treated as untrusted in general, the same as if it was done on the server.

Answer 2

Client side will never be safe. Even though you're using accept attribute in input type="file" , it will only identify the open dialog to identify the given types and show them only. But user can still choose Select All option there and and select any type of file. And reader.readAsText(file); will read it as it is and will not validate. This means hacker can upload anything desired and can inject in the application. Thus, always consider making validation through server side language.

then making the modified version

This will not make any sense since application can upload anything rather than the specified file types.