ACEweb Security Information
Security is a valid concern for any website operator, and an application such as ACEweb that allows online data entry presents a special set of concerns. If your site is public, it is accessible to anyone on the planet with a web browser, so you want to make sure that web users are only getting to the resources you want them to have. In particular, you want to protect your Student Manager data from unauthorized access. Fortunately, many of the best security practices are relatively easy to implement. Some of the primary security considerations for ACEweb (and the Web Connection framework it is build on) are summarized below.

Since Student Manager data is stored in FoxPro data files rather than a separate database, it is essential that measures be taken to prevent unauthorized access to those files.
Rule number one is to make sure that your Student Manager data folder is not part of the virtual web directory structure. While keeping your data on a separate machine from your web server could slightly reduce your risk for direct data piracy, you may find that your web pages take longer to load due to network data access overhead. If you want total security from Web hacking, set up the data server so it is accessed by a non-TCP network connection. (Granted, this is not an option in many situations. However, a TCP/IP based data server should provide adequate security, assuming it has a private IP address and that security patches are kept current.)
If your Student Manager data resides on the same box as your web server (which is the ideal set up from a performance standpoint), you can still achieve good security as long as the data is not accessible via a relative path to your Web site. Typically your Web site will be set up with one or more virtual directories mapped to folders on your server. For example, your Web's home directory might be C:\Inetpub\wwwroot. Under a standard ACEweb install, you will also have a virtual directory named wconnect. Just make certain that your Student Manager folder lies entirely outside of the web directory structure, ideally on a separate physical drive. This will assure that any viewing or modification of the data happens under the control of ACEweb.

If you are using IIS as your Web server, you can make use of Windows file based security. File permissions are validated by the Web server and authentication is requested when the user does not have rights to access a file. When installing IIS, an IIS Internet User account will be set up. Your public content pages must allow access to this user.
The IIS Microsoft Management Console handles most of this for you automatically--when you set up a Web directory it automatically adds the IIS Internet User account to the access list with the file attributes for reading and script access that you provide through the virtual directory dialog. If you need to protect individual files, you can go into Explorer and remove the IIS Internet User account and add special accounts as you see fit.
If you're running ACEweb in File mode, you will need a Temp directory outside of the Web paths that supports FULL access for the IIS Internet User account. To avoid this, and for reasons of improved performance and robustness, we recommend operating ACEweb in COM mode. Note that, in either mode, the IIS Internet User account will need execute rights on the WConnect folder so that it can launch wc.dll.
You will also want to verify that access to the Student Manager data is limited strictly to authorized users. The Manager folder should not be under any of the web directories, and the IIS Internet User account should never be granted any permissions on it.
If ACEweb and your Student Manager data reside on the same machine, ACEweb will run under the SYSTEM account. So the SYSTEM account will need full control to all Student Manager data files.
If your Student Manager/GateCop installation resides on another machine, you must designate a user account for ACEweb to run under. This account should have full control of the ACEweb, Wconnect, Student Manager, and GateCop folders. We suggest creating a domain account called "AWSA" (ACEweb System Account) just for that purpose.

It is assumed that you are using NTFS partitions on your hard drives.

Student Manager and ACEweb use these ports so they will need to be enabled in customer firewalls:
- Data Transfer Ports: TCP 139, 445; UDP 137, 138 are used when transferring data between ACEweb and Student Manager servers
- Standard Email Port: 25 is used by the standard email routine
- Secure Email Port: 587 is used by secure email (SSL) options like gmail
- HTTP Traffic Port: 80 is used for http web traffic
- HTTPS Traffic Port: 443 is used for https web traffic
- SQL Database Users: TCP 1433 and in some cases UDP 1434 are used for transferring data from SQL database to Student Manager and ACEweb

If you will allow users to add/edit personal information, and process credit card charges online, we strongly recommend you purchase an SSL certificate from an authorized vendor, and install it on the ACEweb server.
Once the SSL certificate is installed, you must enable SSL support in ACEweb. To enable SSL:

To enable ACEweb to only send out secure cookies, you will need to update to AW 3.5/4.0 Build .056 or later.
Then add the following line to your awsys.ini:
SecureCookie=ON

Issues in this area can get a bit tricky. Not only is the technical side more complex, but you may encounter resistance from your network systems staff, who will understandably be concerned about the types of traffic that will be passing through the firewall.
If you already have a web server in place behind the firewall, there should not be a problem. Web Connection does not require its own port, as it is not a TCP/IP service in and of itself. As an ISAPI application, it will work in conjunction with the ports that have already been established for IIS (generally 80 for http, or 443 for https).
However, you may encounter a situation where the web server resides in the firewall's "DMZ", thus isolating it from the internal network. The question then becomes one of allowing the web server to "see" the Student Manager data behind the firewall. There are a number of approaches that can be taken.
You may be able to set up a secure "conduit" to the internal data via an IP address that only the web server recognizes. Alternatively, a protected admin or system account on the web server could be allowed access to data drives on the Student Manager servers. If the web server security is set up correctly and maintained this should provide a very robust security solution.

ACEweb must be run on a Windows Server (version 2008 R2 or newer) running Internet Information Services (IIS). ACEweb does run on 64-bit servers if 32-bit compatibility mode is enabled.
In addition, IIS must be properly configured to run ACEweb. Full instructions can be found in Windows Server Configuration.

Keeping your operating system and web server components updated should be part of any standard security routine. Please apply Service Packs as they are released and run the Windows Update option regularly to apply any critical updates that are available. (Note that the recent Slammer attacks only hit systems that were missing the latest service pack, which had been available for some months.) The same is true of ACEweb. We have on occasion discovered security flaws that could potentially put Student Manager data at risk. When that happens, we make every effort to fix the problem and make an update available asap. However, the update does no good until it's actually installed on your server, and for that we must rely on you.

You should restrict access to the Web Connection Server Maintenance Page with the AdminAccount setting in the DLL Settings (WC.ini).
We strongly recommend organizations set up a Network User Account specifically for ACEweb administrators (e.g. 'AWSA' - ACEweb Service Account). This allows you to enlist the help of your ACEware Systems technician with troubleshooting or configuration settings (i.e. you give the technician the AWSA login instead of your personal login when they need to access Administrative pages).
Note: to use a network account, you must also enable Basic Authentication on the inetpub/wwwroot/wconnect folder (Basic Authentication is enabled through the IIS Manager. See your IIS documentation for more information).
Additional security may be applied by setting specific permissions to the /wconnect/admin/ folder. Removing the IUSR account and adding a specified account with read and execute access will prompt for Windows authentication before the admin pages can be displayed. Note: users will still be required to enter a valid Student Manager user name/password to perform tasks.

You should also restrict access to the ACEweb Administration Page. Access to these tools is based on Student Manager security settings. You may set the minimum Student Manager access level a user must have to perform these tasks in the AdminLevel INI setting.
Additional security may be applied by setting specific permissions to the /wconnect/admin/ folder. Removing the IUSR account and adding a specified account with read and execute access will prompt for Windows authentication before the admin pages can be displayed. Note: users will still be required to enter a valid Student Manager user name/password to perform tasks.

If you will be accepting and processing credit card charges online, we recommend using one of the redirect-type payment services, where users are transferred to the provider’s website to enter their card transactions. The credit card information is never stored on the ACEweb/Student Manager system and the payment service takes on responsibility for PCI compliance.
We support a number of redirect-type payment services, including PayPal Payflow Link, CyberSource, Authorize.net, CashNet, Elavon, and Touchnet uPay.
For a full list of supported payment service, please see our Partners page:
If you do use a service that requires entering the credit card information via the ACEweb payment page, we strongly discourage storing credit card numbers in the Student Manager database. Either select the option to blank the credit card number after the charge is processed, or to only store the last 4 digits of the card.

Although each ACEweb hit requires a call to the wc.dll library, it is no longer necessary to explicitly include direct references to the dll in your URLs. By default, ACEweb now uses a script map to link the extension .awp to the wc.dll file on the web server. This makes for “cleaner” URLs and improves web server security by removing the dll as an exposed target for hackers.