Security Considerations

Securing applications that are accessible to the Internet is not a trivial task. This page outlines some of the issues, and offers tips to help you secure your application using the Embedthis Appweb product.

Updates

Even the best application or HTTP server can experience some security vulnerabilities that are discovered after being deployed in the field. It is highly recommended that you stay up to date with the latest version of Appweb.

Embedthis provides security protection as part of the Appweb commercial license that will proactively notify you of any security flaws and will expedite fixes or workarounds to minimize the vulnerability.

Sandboxing

Sandboxing is the term applied to running Appweb in a confined environment. When embedding a HTTP server, the profile of client access is often well known, and the profile of malicious attacks are well outside this profile. The profile includes the rate of accesses, the length of URLs and the size of pages returned to the user.

Appweb has a set of configuration file directives that allow you to define a sandbox which specifies how Appweb must be used for a request to be serviced. By using well defined sandbox directives, you can help ensure that your application will not be compromised by malicious requests. You should customize the sandbox limits to use minimum values and thus provide the most protection.

Security Limit Directives

The Appweb security limits can be used to effectively block some denial of service attacks. Setting the LimitRequestsPerClient to a low value can restrict the ability of a malicious client to monopolize the server. One attack method for denial of service attacks is to initiate requests, but not conclude the request headers. The server is then forced to wait for the client to complete the request before it can act. However, setting the RequestParseTimeout directive to a low value will abort such requests and prevent such attacks.

The important security limit directives are:

InactivityTimeout	Maximum request and connection inactivity duration. This can be defined per route, so if you have a long running request, create a dedicated route for that request.
LimitClients	Maximum size of simultaneous clients
LimitRequests	Maximum number of simultaneous requests
LimitRequestsPerClient	Maximum number of simultaneous requests from a single client IP
RequestParseTimeout	Maximum duration to parse the request headers. This should be set very short. Typically a browser will send all the request headers in one network packet. Recommended value is 5 secs.
RequestTimeout	Maximum request duration. Set this to the maximum time a request can take. This can be defined per route, so if you have a long running request, create a dedicated route and RequestTimeout for it.

Sandbox Limit Directives

The additional sandbox limit directives are:

LimitBuffer	Pipeline stage buffer size
LimitCache	Maximum size of the response cache
LimitCacheItem	Maximum size of a single item in the response cache
LimitChunk	Maximum size of chunks when using Transfer Chunk Encoding
LimitKeepAlive	Maximum number of requests to serve using a single TCP/IP connection
LimitMemory	Maximum memory the server can allocate
LimitRequestBody	Maximum size of the incoming request body
LimitRequestForm	Maximum size of request form data (POST data)
LimitRequestHeader	Maximum size of the request header
LimitRequestHeaderLines	Maximum number of header lines in the request
LimitResponseBody	Maximum size of a response
LimitUri	Maximum size of a URI
StartThreads	Number of threads to pre-allocate in the thread pool
LimitUpload	Maximum size of a file upload request
LimitWorkers	Maximum number of worker threads to service requests

See the Sandbox Directives for further details.

Appweb User Account

It is important that you run Appweb with the lowest system privilege that will get the job done. If any application is compromised, including Appweb, then the system will be safest if the compromised application has as few privileges as possible.

Unix Account

On Unix, Appweb initially runs as root or administrator and then changes to the user account defined in the Appweb configuration file via the User directive. As installed, Appweb will be configured to run in the nobody account on Unix. You may modify the user and group account for Appweb by changing the Appweb configuration file.

Windows Account

On Windows, when running as a system service, Appweb will run using the LocalSystem account. This account has no privileges to access the network using network drives, named pipes, RPC or DCOM. However, it has considerable privileges locally. It is suggested that you create a dedicated account for Appweb to minimize the privileges available should Appweb be compromised.

When creating an account for Appweb, ensure you do the following:

• Using the Group Policy manager, grant the account the privilege of "Act as part of the operating system" and "Log on as a service".
• Ensure the account is a member of the "Users" group.
• Give the account read and execute rights to all HTML documents.
• Give the account read, write, execute and delete rights to the logs directory.
• Give the account read and execute rights to the appweb.exe and the DLLs in the libs directory.

Directory and File Permissions

When Appweb is installed, it is configured for maximum security. This section explains the policy should you need to move or modify files and directories.

To enhance security you need to consider the directory and file permissions for three classes of content:

• Pages served by the HTTP server
• Scripts run by the HTTP server
• Configuration and log files used by the HTTP server.

Pages served by the Appweb server should be owned by root or administrator and should be only readable by the Appweb user account. Directories containing served pages should be readable and executable only.

Scripts run by the Appweb server should always be outside all directories containing served pages. After all, you don't want prying eyes viewing your scripts! Scripts should be owned by the root or administrator and should only be readable and executable by the Appweb user account.

Configuration and log files used by the Appweb server should always be outside all directories containing served pages or scripts. The directory containing the log files must be writable by the Appweb user account.

Home Directory Permissions

The root directory for Appweb is called the Home directory and is defined by the Home directive in the configuration file. The Home directory, and the logs and lib directory below it, should be owned by root (or admin), and should be in the group root (or administrators). They should only be writable by this specific user and group.

For Linux, these commands will ensure the privileges are correctly set up:

cd    /etc/appweb
chown root . lib logs
chgrp root . lib logs
chmod 755  . lib logs

Dynamic Content

Appweb supports several Web Frameworks for creating dynamic content. These frameworks sometimes require special security considerations because they are executing code or scripts to render the content.

Ejscript Web Framework

Appweb supports the Ejscript web framework for dynamic web applications. Ejscript will execute HTML pages with embedded script code and process the pages before returning the result to the client. Properly configured, your scripts will not be readable by users and they will only see the generated content.

To keep server-side scripts private, you must have the Ejscript handler configured to process the required script extensions or URL prefixes. If a script extension is not configured, the file handler may process the page and return the raw script back to the user. As installed, Appweb defines the ".ejs" extension for Ejscript pages. Using the EjsAppAlias directive will correctly configure an Ejscript application to prevent access to raw script code.

PHP

The php.ini file controls the setup and execution of the PHP web framework. The following table lists several parameters that should be set for enhanced security:

Parameter	Description
safe_mode = on	When safe mode is enabled, PHP scripts can only access a file if it is the owner of the file. This prevents access to system files.
safe_mode = on	When safe mode is enabled, PHP scripts can only access a file if it is the same group as the file. This prevents access to system files.
open_basedir = directory[:...]	Define a set of directories that will be the only directories for files that PHP can access.
safe_mode_exec_dir = directory[:...]	Define a set of directories that will be the only directories from which PHP can execute programs.
expose_php = off	This causes PHP to run in silent mode and not disclose information about itself.
display_errors = off	This causes PHP to write errors to the log rather than sending them to the client's browser.
register_globals = off	When enabled, register_globals will also define many request variables as global variables. This can be a serious security threat.

Changing the extension

To obscure the fact that PHP is being run on the server-side, you can change the extension for pages from .php to say ".web". You then need to add the following directive to the appweb.conf file.

AddType application/x-httpd-php .web

Embedded Server Pages

ESP applications are not immune to security flaws. It is highly recommended that you use the MPR services for all your ESP code. This portable runtime has been extensively tested and includes routines to guard against common buffer overflows and other such exploits.

SSL Servers

If you configure a SSL virtual server, remember to define a separate Documents directory if you want to only serve private content to SSL users. Otherwise those pages will also be visible via the default server.

Authentication

It is highly recommended that you use only Digest authentication and not Basic authentication. As implemented in Appweb, digest authentication provides many safeguards against known exploits including; man-in-the-middle attacks, client spoofing, and replay attacks.

Log Files

Appweb will log satisfied requests to the access log (usually logs/access.log) and errors to the error log (usually logs/error.log). It is recommended that you regularly review these logs for suspicious activity.