Qualys WAS raises "150004 Path-Based Vulnerability" on an image file

Question

Customer is running Qualys Web Application Scan and the WAS Scan Report reported:

150004 Path-Based Vulnerability

on URL: https://www.example.com/mywebapp/Content/datepicker/images/ui-icons_444444_256x240.png

I have verified that Directory Browsing is disabled in IIS 10, per How to fix Path Disclosure Vulnerability?. Browsing to https://www.example.com/mywebapp/Content/datepicker/images raises 403 - Forbidden: Access is denied

I can browse directly to the image at https://www.example.com/mywebapp/Content/datepicker/images/ui-icons_444444_256x240.png and visibly see it. F12 tools displays a Status=304 for the file

I tried to adjust access by adding a web.config with the following

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
    <system.web>
        <authorization>
            <allow users="*" />
            <deny users"?" />
        </authorization>
    </system.web>
</configuration>

This locks the image file from view but it also breaks the jQuery UI date picker in the application: F12 console raises an http 500 on the image load and the date picker is missing navigation arrows (and this is when the user is authenticated in ASP.NET and not anon (authenticated user="*", anon user="?") and is using the date picker to select dates).

When I remove the above web.config, the datepicker reverts back to working but I'm back to square one with the red flag from WAS.

Is this something that I can address with an authorization setting in web.config or other ACL without breaking the datepicker? Perhaps I'm chasing a false positive?

Answer 1

I'm also trying to figure this one out. So far my conclusion is that you should not block access to js, css or image files in a web application, that is the way is supposed to be. In my case the scan tool seems to be reading the path of an image(which you can manually do by right click on an image and click on copy image link..) and then changing the image name by a random folder name like Service. The app is returning a 200 status code that contains an error page that doesn't disclose info, it just tell you that something went wrong and suggest you to go to the home page...so in this case I think it should be considered a false positive.

As a side note, if a client wants extra protection of it's images there are some techniques, depending on the technologies been used, that can be applied. A quick search will show some ideas on stackoverflow, but they are programmatic solutions.

Answer 2

Maybe it's due directory traversal.

Try to access another app and another file using directory traversal. Something like https://www.example.com/mywebapp/../myanotherapp/sample.txt