Securing Your Server

This page is not meant to be a comprehensive discussion on how to secure your Web server. It is just meant to point out some of the more common vulnerabilities we have seen and offer suggestions on how to get around them. The security of your data is a matter that should not be taken lightly, so we highly recommend that you research the subject thoroughly. There are several resources available that can help you protect your Web server from external attacks.

Preventing your data and programs from being downloaded over the Web

Most FoxWeb applications are typically comprised of multiple components: source code (FWX and/or PRG files), compiled programs (FXP files), data files, and static content such as HTML files and images. Depending on the Use Web Server Directory Mappings setting, your FXP files and possibly your source code will reside in a directory within the Web tree, where if they are left unprotected they will be accessible over the Web. In order to avoid exposing your source code and data to the world, you need to do one of the following:

• Disable "Use Web Server Directory Mappings", and keep your programs and data files in an unmapped directory, where they can not be downloaded over the Web. The disadvantage of this method is that you will have to keep your static content in a separate directory in the Web tree. Your script-generated HTML may even have to refer to these static resources with absolute URLs, which are not portable.
• Keep your source code in a directory outside the Web tree, possibly on a development server. All FoxWeb needs in order to run your code is the FXP files.
• Keep your data files in a directory outside the Web tree. Of course this means that your USE, SELECT statements will have to refer to your files with a fully-specified path, but this is a small price to pay if security is important to you.
• Another solution is to configure your Web server, so that it does not allow the direct retrieval of files that should not be downloaded. If your Web server does not support the ability to prevent retrieval, based on file extension, you can also map the extensions of these files to a program that simply returns an error message. The FoxWeb setup program installs the file deny.exe, which can be used for this purpose.

"Full Paths in URLs" option

This setting is configurable via the FoxWeb Control Center and is included for backward compatibility. If this option is enabled, then FoxWeb will allow URLs that contain a full path, such as http://servername/c:/MyScripts/name.fwx. We highly recommend that you disable this option. You should only consider enabling this option in situations where you want to get an old FoxWeb program that relies on this feature up and running immediately and do not have time to modify it, so that it does not need to use full URLs. Even so, you should make the necessary modifications as soon as possible to close this possible security hole. Under no circumstances should you ever enable this option if your server allows posting of files via the Internet, such as when you are running a public FTP server with upload permissions turned on.

Controlling what FoxWeb scripts can do

In some cases it is desirable to control the type of access FoxWeb scripts have on the server. This is especially important in cases where the system administrator does not have control over the content of scripts. In Windows NT and Windows 2000 FoxWeb scripts have the same privileges as the user that FoxWeb is running as. If FoxWeb is running as a service then you can specify the FoxWeb service user in the Services applet of the Control Panel. If, on the other hand, FoxWeb is running on the desktop as a regular application then it has the same rights as the user that is currently logged into the system.

FoxWeb requires a baseline set of access rights in order to function. It obviously needs read and possibly write access in a number of directories, including the FoxWeb directory, all its script and data directories, the TEMP directory, as well as the WINNT and System32 directories. It also needs access to all ODBC drivers, COM objects and remote resources that your applications are using. You will need to experiment with different access rights until you find a set that is restrictive enough, but still meets your application's needs. It is usually easier to develop your programs, while FoxWeb has a full set of rights. Once the application is tested, you can start experimenting with a more restrictive set.

Other kinds of attacks

Public Web servers are prime targets for hackers, because by nature they have to be visible to the Internet. There are several 3rd-party solutions, which can make your system a lot more resilient to such attacks. We recommend a combination of a firewall and a proxy server, which will essentially hide your Web server behind a virtual wall and make it inaccessible to direct Internet traffic. The proxy server will play the role of the middle man, handling the task of passing Web-related traffic between the Web server and the browser.

A slightly simpler solution is to have a firewall/NAT (Network Address Translation) configuration, where the server sits behind the firewall and is only accessible to Web-related traffic (usually ports 80 and 443). Even though this solution is not as secure as having a proxy server, it is probably adequate for most sites.

Note that the above configurations require advanced knowledge of networking and Internet security, so you may have to obtain the assistance of a security consultant in order to implement them; however, if your data is of sensitive nature, such solutions are certainly worth looking into.