6. The application vulnerability assessment
6.3. File upload issues
6.3.4. improper filtering of upload procedure
In the order submitting form, you will notice that only .gif images are accepted. Is it really true? Let’s create the following attack.html file:
<html> <body>
<script>alert('XSS');</script> </body>
</html>
The application does some sort of the check against uploaded files. In order to verify what sort of protection is implemented, we can use the following actions.
First it is always good to try to upload several different properly formatted files (for example .html, .htm, .bat, .exe, .com, .txt, .js etc) and observe how the tested application behaves.
This method allows an attacker to check what approach the verification procedure uses. It tries to answer the question whether the application uses a blacklisting or whitelisting approach. The blacklisting approach defines the list of extensions, which are not allowed by an application, whereas the whitelisting defines the list of extensions, which are allowed and blocks all others. Of course the more secure approach is whitelisting, because it is always possible to miss something important in blacklisting approach.
In case of the ButterFly application the attempts to upload different types of files fails with the same error message as you can see above.
Therefore, it seems the ButterFly application accepts only .GIF images. However, the question arises on what basis the application decides that the uploaded file is really GIF. Does it concern the file extension, Content-Type header during upload submitting or maybe it is inspecting the content of the file?
Let’s begin with the changing of the file extension first. However, this can not be done just by renaming a file. During the upload procedure a web browser can additionally detect the true type of the file and change the Content-Type automatically. Therefore, it is needed to make this change during the file upload. This can be done using request interception feature of many free web proxy applications (webscarab, paros etc).
Below you can find the fragment of the request during the upload. The highlighted text should be changed to ‘attack.gif’.
Securing PHP applications
Next submit the request to the application using web proxy tool. In result I got the error message again.
Now let’s try to check the Content-Type header. Below you can find the fragment of the request during the upload. The highlighted text should be changed to ‘image/gif’.
This time the result is the following:
[…]
---7d8ab6230686
Content-Disposition: form-data; name="uploaddoc"; filename="C:\test\attack.html" Content-Type: text/html <html> <body> <script>alert('XSS');</script> </body> </html> ---7d8ab6230686
Content-Disposition: form-data; name="comment" […]
[…]
---7d8ab6230686
Content-Disposition: form-data; name="uploaddoc"; filename="C:\test\attack.html" Content-Type: text/html <html> <body> <script>alert('XSS');</script> </body> </html> ---7d8ab6230686
Content-Disposition: form-data; name="comment" […]
Success! It was not so difficult this time. It turns out that the application verifies only Content-Type field. The consequences of this vulnerability usually depend on how the application presents to a user the uploaded files. In order to make this vulnerability exploitable, the application has to contain additional vulnerability in the presentation layer.
This vulnerability can be easily revealed by checking the details of the submitted order and clicking the preview button. The behaviour of the application can confirm quickly the vulnerability, show how you need to modify the attack to be successful or just deny the exploitability.
After clicking the PREVIEW of the last submitted order, the result is the following:
Again success! The web browser executed my JavaScript code, which was kept in the uploaded file. Let’s check what HTTP request and answer look like during the preview button click.
The request: GET http://insecure.butterfly.prv/preview.php?f=34 HTTP/1.1 Accept: */* Referer: http://insecure.butterfly.prv/orders.php Accept-Language: en-gb UA-CPU: x86
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Paros/3.2.13
Proxy-Connection: Keep-Alive Host: insecure.butterfly.prv
Cookie: sid=bd464347201114cdf0367c96f512012f27b6f92b
Securing PHP applications
The ButterFly application preview behaviour shows one of a number of common programming errors. The assumption that a user uses the most popular browser: Internet Explorer. The application tests confirmed that the preview functionality works. However, the tests were done only under Internet Explorer. Further more, this functionality exploits one of the Internet Explorer features. It is the content auto-detection.
In the application answer there is no information that the transmitted file is a GIF image. It is the web browser, which recognises the file type and reacts accordingly to it. If it is a GIF image, it will be presented to a user inside the web browser. However, if it is a HTML file like in my example, the web browser will try to interpret the code and present it to a user.
HTTP/1.1 200 OK
Date: Fri, 11 Jan 2008 14:43:24 GMT Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache
Set-Cookie: sid=bd464347201114cdf0367c96f512012f27b6f92b; path=/; domain=insecure.butterfly.prv Content-Type: application/octet-stream <html> <body> <script>alert('XSS');</script> </body> </html>