Security vulnerabilities related to file uploads (Part 2)

Tram Ho

You can read Part 1 here .

3. Cross Site Scripting (XSS) vulnerability when downloading files

3.1 General

When the user downloads the file, there are cases where the browser gets mistaken for the file type. For example, although the application assumes it is a png image file, when including the HTML tag in the image data, depending on the condition, the browser will misunderstand the HTML file and run the JavaScript in the image file. image. This is known as Cross Site Scripting when downloading the file (XSS).

An attacker taking advantage of this vulnerability will upload an image file or a PDF file containing HTML or JavaScript and then publicize it. This file will not be recognized as HTML in the correct reference, but when an attacker traps the user, the uploaded file will be recognized as HTML. When the user’s browser identifies this file as HTML, an XSS attack will occur.

The solutions to XSS vulnerabilities when downloading files include the following measures:

  • Set the correct Content-Type of the file
  • Verify that the image extension and image content (magic byte) correspond to each other
  • In the file you intend to download, specify [Content-Disposition: attachment] as the Response Header

3.2 Attack and influence techniques

In this section we will introduce examples of techniques for XSS attacks when downloading files. The attack technique introduced here can be reproduced in Internet Explorer (IE). Browsers other than IE may not be able to play again.

◆ XSS by image file

It is possible to trap an XSS attack by uploading a fake image file containing HTML or JavaScript.

Here we will see, even if we implement the policy that prevents the script from being run on the Server explained in Part 1, there is a possibility of a Cross Site Scripting attack when downloading.

The source code handles upload as follows:

Upload.php

Then create the JavaScript file as follows and name the file “image.png”.

Upload this fake image file (Upload.php). Then click on the file name in the message screen Upload successful. At this point the Script script will be run.

The effect of an XSS attack with an image file is similar to that of a regular XSS attack. It is capable of tampering by stealing cookie values, abusing Web functionality, or phishing by changing screens …

3.3 The cause of the gap

Of the reasons that cause XSS vulnerabilities to download files, Internet Explorer-specific features are somewhat affected. Internet Explorer in addition to the Content-Type Header of HTTP Response, also uses the extension on the URL and the content of the file to identify the file type. Although it is not public, it can be understood that it is divided into the following cases.

◆ Where the content is an image

In addition to the Response Header Content-Type, the magic byte of the image file is also used to identify the file type. Magic byte is a fixed string of characters placed at the beginning of the file to identify the file type. For example, the magic byte of GIF, JPEG, and PNG is as follows:

Image TypeMagic bytes
GIFGIF87a or GIF89a
JPEGxFF xD8 xFF
PNGx89PNG x0D x0A x1A x0A

Internet Explorer (7 and earlier) will perform the following file type recognition in its default settings.

The case that magic bytes are identical to the Content-Type

In this case, use the file type displayed in Content-Type.

The case that magic bytes are not identical with the Content-Type

In the case of displaying file types where magic bytes and Content-Type are different, then ignore both, performing speculation of file type from the content of the file. There are also cases if an HTML tag is included in the body of the file, then identified as HTML. The rogue PNG file introduced in [XSS by image file] will work for this. The sample file does not include the magic byte image, but even if it does include the magic byte, the conflict with Content-Type is also ignored.

◆ Where the content is not an image

If it is not an image, it will feature the following regardless of the version of IE.

The first, depends on whether IE can handle the Content-Type or not that the behavior will change.

In case Content-Type belongs to IE’s treatment, IE will handle it based on Content-Type type. Content-Type belonging to IE handle will be registered to HKEY_CLASSES_ROOT ¥ MIME ¥ Database ¥ Content Type of Registry.

Where Content-Type does not belong to IE, IE will determine the file type based on the extension in the URL.

3.4 Opposition

The countermeasures of the XSS vulnerability when downloading files are the measures taken when uploading files and downloading files.

◆ For books when uploading files

When uploading files, take the following measures:

  • Check if the extension is accepted or not
  • For the image, confirm the magic byte. Regarding the method of checking the extension, it was explained in the argument of [Running Script on Server by file upload] (Part 1)

When validating the magic byte of the image, for PHP we can use the getimagesize function as follows:

This function will take the filename as an argument, returning the width, height of the image and the image as an array. Below will introduce some values ​​and constants of commonly used image shapes. For details, please refer to the PHP manual.

ValueConstant
firstIMAGETYPE_GIF
2IMAGETYPE_JPEG
3IMAGETYPE_PNG

◆ For books when downloading files

For books when downloading files, there are the following measures:

  • Content-Type Correct Settings
  • For images, accept magic bytes
  • Install Content-Dispositon as needed

⧫ Correct Content-Type setting

When an XSS vulnerability occurs that spoofs PDF files, the main reason is due to Content-Type confusion. If the Content-Type of PDF is set correctly to [application / pdf] instead of application / x-pdf, the vulnerability will not occur. Setting the correct Content-Type is a must-have not just for IE but for all other browsers as well.

⧫ For pictures, confirm magic byte

When downloading the file, if we confirm the magic byte even when downloading, even for some reason, the fake image file merged into the Web Server we can still perform the authentication policy.

⧫ Set Content-Disposition when needed

If the downloaded file is not open with the app and still can be downloaded, there is a method of specifying the Response Header as [Content-Disposition: attachment]. In this case, when Content-Type is also set to [application / octet-stream], the file type also means [file to download]. The following are examples of these header settings.

◆ Other responses

The countermeasures explained so far only revolve around checking the minimum bounds required to prevent gaps. For example, just checking the magic byte cannot confirm whether it is actually displayed in the user’s browser or not.

Therefore, when looking at the properties of a Web application, it is necessary to check whether the following tests are performed.

  • Check for other factors besides size, like: width, height, weight …
  • Check if readable as picture or not
  • Scan for viruses
  • Content inspection (automatic or manual test)

Submit images with Private Domain

Since around 2009, there have been Web sites sending images with a separate domain other than the domain used to provide services. Below are examples of Web sites that submit images using Private Domains.

Site namePrimary domainDomain used for images
Yahoo! JAPANyahoo.co.jpyimg.jp
YouTubeyoutube.comytimg.com
ニ コ ニ コ 動画nicovideo.jpnimg.jp
Twittertwitter.comtwimg.com
Amazon.co.jpamazon.co.jpimages-amazon.com

These are Web sites with a lot of information exchange, the reason for separating separate image domains to improve speed is also common, but the division of separate image domains like this is also effective in terms of security. By storing content such as images, PDFs, … in a separate Domain, even if XSS attacks occur, it will not affect the service.

Over.

Share the news now

Source : Viblo