EXIF Cross Site Scripting, PHP Fun

As most security folks know, there are numerous ways to infect computers via infected image files, that contain binary viruses which are read/invoked by different image readers or the libraries that render them.

From my perspective, looking into web application security, I had an idea..

Many websites and applications nowadays, look into the picture’s EXIF information in order to extract valuable data such as the size, date, exposure, geo location, and basically any meta piece of information. well, some of the attributes are writable :)

I decided to design an experiment that will check if we can inject code directly into an EXIF tag and see if the application interpreters will execute on it. Even though I am sure that this sort of experiment has already been done in the past, but learning through experimenting is what I live for.

The Experiment

The experiment breaks into 2 sections:

  1. Will a standard JPG accept characters that are required for a simple Cross Site Scripting attack
  2. Will industry standard interpreters execute on the EXIF tags when read

First thing I did, was to install exiftool and reading the metadata off a picture that I took with my smartphone, and looked for an updatable EXIF field. For sake of this experiment, I went for the “Comment” tag, and simply wrote “barry” in it.


As you can see, the field was updated. Now, to conclude the first part of our experiment, I updated the field with a simple XSS test string to see that its accepted. It was.

We can conclude that the EXIF field accepts any character, and in specifically a string that is required for a XSS attack.

To check the second part of our experiment, I used a PHP server on a commercial hosting service (which is running what they consider their best practice PHP deployment), uploaded the manipulated image, and created the following code to display the EXIF information:



It is important to note that exif_read_data is a standard PHP function that reads the EXIF information into an array, and I used the “echo” command to loop through the output.

Here is the result:


We have therefor proved the second test in the experiment, there was no problem displaying an unchecked string from EXIF and running it as standard script. the XSS vector is valid.

Who Should Care?

With many websites accepting image uploads (some through mobile interfaces), and analyzing EXIF information to determine resolution, location, owner and other pieces of data – there is a risk of a web application attack. In this case we have achieved an XSS (Cross Site Scripting) attack, but this information could have been extracted/inserted into a database – enabling SQLi (SQL Injection) attack on the database.

The underlying problem does not reside in a simple echo of the malicious string.  Meta data is usually saved within the application database, on an application that parses through this kind of information (lets take any image broker including some of your favorite mobile apps). they keep this kind of meta data for indexing and search purposes. this effectively means that one could inject a Persistent XSS or an SQLi string into the database, and have it execute under certain conditions. not a good thing.

I believe that it is important to run filter engines on EXIF metadata just as if it is a normal web attack or a script injection vector.