In addition to dealing with application based security you also need to thinK about securing your Web Connection installation. In particular, Web Connection ships with maintenance modules that are accessible through HTML interfaces which are Web accessible. If these interfaces are publically exposed they can cause serious security risks to your online application.

The first step is to understand that Web Connection consists of two components, which both expose administrative functions:

• The ISAPI extension
  wc.dll includes a number of admin functions that deal with managing the server to Web Connection connectivity. It administers server management and code update features especially for operation in COM mode. You can also switch the server between COM and File operation through this interface.

• The Web Connection Server
  The Web Connection contains a wwMaint module which is used to configure internal setting of the Web Connection server. Most importantly it includes an edit link that allows edit the configuration files directly over the Web.
  

Enable Basic Authentication

In order to use Web Connecion's internal security blocks against access you should enable Basic Authentication on the Web Server either for the entire Web site or for the virtual directory that your application lives in. Setting the Admin passwords will use Basic Authentication and NT Security for checking access to these functions.

The ADMIN.ASP page

The admin page (ADMIN.ASP) serves as a central administrative page to all the administrative features available. To secure admin functions your first step should be to restrict access to this page via NT file permissions. Allow only Administrators (or individual users) access to this page. To do this find the page with Explorer in your Web directory and use the Security settings and remove the IUSR_ account from access to this page and add in Administrators or the specific users you want to have access to this page.

The wc.ini file and the AdminAccount key

wc.ini (or a renamed version thereof that matches the name of your DLL) contains a number of important settings that control how your Web Connection server interacts with the Web server.

The most important setting in terms of security in this file is the AdminAccount key which determines who has access to the wc.dll admin function. Admin functions are typically accessed through wc.dll?_maintain~Command syntax through the URL interface. These requests never hit your FoxPro Web Connection application - they're processed directly by the DLL and not passed any further.

It's important that you secure the AdminAccount to an Administrative account or a list of accounts that will be granted access. For example, on my site I allow myself and Markus Egger admin access. So I have an entry like this:

AdminAccount=ricks,megger

Now anybody accessing any of the admin links will be prompted for a password and username. If you don't authenticate properly access will be denied to any of the admin links.

Note
If your security is extremely sensitive I recommend you only access the ADMIN.ASP securely through HTTPS. This will prevent possible hacking of passwords via basic authentication that sends passwords in clear (or easily cracked hashed format) over the wire. The additional HTTPS security protects your passwords from hackers.

The wc.ini file AdminAccount setting is also the default security account used for the Web Connection server admin features. The following code in wwMaint.prg validates users using Basic Authentication:

   *** Only allow Admin account from WC.INI
   *** and authenticate. If no success don't let on
   IF !THIS.Login("WCINI")
      RETURN 
   ENDIF   

The above code also uses the WC.INI admin account setting to validate access to any wc.dll?wwmaint~Command links. You can override this behavior to any that you choose, but the default is a good mechanism to provide the same security for both the wc.dll security as well as the Web Connection server security.

Securing WC.INI

In addition you can also lock down wc.ini itself so that nobody can view the file over the Web which is possible with the default IUSR_ permissions. This file contains semi-sensitive information, which by default can be openly viewed over the Web. If you do http://localhost/wconnect/wc.ini you will actually get the contents of the INI file in the browser. I don't consider this a big security risk as long as you followed the above steps, but some admins will want to lock down this file as well. You can do this by removing rights for all users but Administrators and the SYSTEM account. Make sure the SYSTEM account has access to the file, because that's the context wc.dll uses to access the file for various maintenance requests.

Scripts and input forms

If you rely heavily on template forms and ASP like expansion tags be aware that it may be possible for a remote user to post a message that containing script tags that may get evaluated on the server. Those script tags can potentially execute damaging code as the server side parses this code (this BTW is a problem for any script based engine like WWWC, ASP, Cold Fusion etc.).

For example, if you take user input in any way and echo it back to the user and the user enters a script tag like <%= Version() %> you can potentially see the actual version embedded instead of the HTML markup! Obviously more dangerous commands and blocks of code could be used instead. The solution to this problem is to always translate posted code into display only HTML by using functions like FixHTMLForDisplay() which takes any HTML tags and converts them into display only text. Failure to do so can cause serious security issues as potentially all of the power of VFP is available to an outside user.

Form and QueryString security

If you are running dynamic queries and/or execute commands directly from user input you have to be very careful about the input you receive. It's possible that input can be formatted in such a way that the command that you are running - such as a SQL statement with a WHERE clause constructed with the Form() or QueryString() input - is actually formatted to execute a command. For example, it might be possible to smuggle in a call to EVAL, EXECSCRIPT, STRTOFILE or other VFP command. To prevent this Web Connection includes a security feature that filters Form() and QueryString() requests by checking for common dangerous expressions.

To use this set the WCONNECT.H flag WWWC_FILTER_UNSAFECOMMANDS, or use the wwRequest::lFilterUnsafeCommands property to provide basic filtering of the input string. This filter function is limited at best but it provides a good baseline to protect for basic hack attempts - unless somebody is extremely familiar with the way Web Connection and VFP works and has some knowledge of the code beneath the request it'll be unlikely to be exposed to attack. For ultimate security, we recommend that you carefully filter any parameters that you pass to SQL statements or other macro or EVAL() type processes that execute user input directly.

Web Services

Generic Web services such as the HTTP SQL service (wwHTTPData) and the HTTP Remote COM method call interface (wwHTTPCOM) are potential security openings if left unchecked. By default these services use passwords to force logins. By default these won't work. New projects also don't install the hooks to use these services - they must be hooked up manually. However, the demo server has them open and connected.

To disable these services check your main program's Process method and make sure the the wwhttpdata processing is commented out in the CASE statement.

These services can be configured to allow access by specific users (cUsername and cPassword properties) and the SQL service can be configured to allow only certain SQL commands like SELECT or EXECUTE. The COM service allows inclusion or exclusion lists of objects so you get flexibility in what's allowed. View the appropriate docs for these objects for details.