AVFP Security- Lockdown VFP file extensions

Topics: Developer Forum
Developer
Nov 5, 2013 at 2:25 PM
I doubt AVFP has any need to call VFP files from browser. If not, then maybe it'll be better to lock down these files in IIS.

If you are running .net framework ver 4.0, then I propose we change the web.config in our AVFP application 'root' as follows
  <system.webServer>


    <!-- The all VFP file Extensions  i.e. .prg .fxp etc need to be disabled from being called from browser 
         The following will work in non-debug mode only.

     Also, to force the ajax calls to work.. we are setting the Access-Control-allow-origin setting to least security level.. Pending.. cor
      -->                   
    <security>
        <requestFiltering>
            <fileExtensions>
                <add fileExtension=".prg" allowed="false" />
        <add fileExtension=".fxp" allowed="false" />
        <add fileExtension=".bak" allowed="false" />
        <add fileExtension=".cdx" allowed="false" />
        <add fileExtension=".dbc" allowed="false" />
        <add fileExtension=".dbf" allowed="false" />
        <add fileExtension=".dll" allowed="false" />
        <add fileExtension=".ocx" allowed="false" />
        <add fileExtension=".pjt" allowed="false" />
        <add fileExtension=".pjx" allowed="false" />
        <add fileExtension=".tbk" allowed="false" />
        <add fileExtension=".vct" allowed="false" />
        <add fileExtension=".vcx" allowed="false" />
        <add fileExtension=".dcx" allowed="false" />
        <add fileExtension=".err" allowed="false" />
        <add fileExtension=".exe" allowed="false" />
        <add fileExtension=".fky" allowed="false" />
        <add fileExtension=".fll" allowed="false" />
        <add fileExtension=".fmt" allowed="false" />
        <add fileExtension=".fpt" allowed="false" />
        <add fileExtension=".frx" allowed="false" />
        <add fileExtension=".idx" allowed="false" />
        <add fileExtension=".dct" allowed="false" />
        <add fileExtension=".app" allowed="false" />

            </fileExtensions>
        </requestFiltering>
    </security>
     <httpProtocol>
          <customHeaders>
              <add name="Access-Control-Allow-Origin" value="*" />
          </customHeaders>
     </httpProtocol>
  </system.webServer>
Anyone see problems with this?
Developer
Nov 5, 2013 at 2:48 PM
Also, if you are implementing debug in ver 6.03 as per my previous email then..

then change the config file for windows authentication and set-up folder permissions as per your requirements.
 <system.web>
    <authentication mode="Windows" />
  </system.web>
Coordinator
Nov 5, 2013 at 9:44 PM
I thought those types of files were in folders inaccessible to a web browser?

Could you give an example URL to the demo site where you can call or bring up one of these files in a browser?
Developer
Nov 6, 2013 at 12:16 AM
Hi Claudefox,

You are correct. We do not have these files accessible in ver 6.03.

However, I was just trying to addrress security issues in Avfp which came up during my QA. I've handled them little differently in my version which is not relevant in AVFP 6.03. However, my intension was to give AVFP developers some food for thought on hiddenSegments,fileExtensions etc before they release apps into production.

Regarding the URL.

Try this, which is our demo site in codeplex . I've used a simple file ( just to let you know I had no dire intentions), but this could easily have been a more nasty VFP file.

Disgruntled ex-employees have been know to do worse.
Coordinator
Nov 6, 2013 at 3:20 PM
Thanks. It's not much of an exploit though since you can easily change the Upload directory (which goes to /Temp I believe) to something you can't view.
Developer
Nov 7, 2013 at 3:47 PM
Yep, it's not a big deal to handle but easy to overlook.

It took me much longer to figure it out. I normally delete these files within 4 minutes. That short period was enough to move permanently into another folder. Lucky this was just testing otherwise could have been nasty indeed.

Having sample fileExtensions/hiddensegments in web.config would provide a hint to developers to pay attention to these details too, I would think.