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
Mbedthis Appweb product.
 UpdatesEven 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.
Mbedthis offers a Security Enhancement Service as part of the commercial license that will
proactively notify you of any security flaws and will expedite fixes or workarounds to minimize
the vulnerability.
Appweb User AccountIt 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.
On Linux, Appweb initially runs as root or administrator and then changes to the user account defined in the Appweb
configuration file. As installed, Appweb will be configured to run in the nobody account on Linux. You may modify the user and group account for Appweb by
changing the configuration file.
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 priviliges 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 used, incase 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 the directory containing served
pages. After all, you don't want prying eyes viewing your scripts! Scripts should be owned by
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 the directory
containing served pages or scripts. The directory containing the log files must be writable by
the Appweb user account.
ServerRoot PermissionsThe root directory for Appweb is called the ServerRoot directory
and is defined by the ServerRoot directive in the configuration file. The ServerRoot
directory and the logs and lib directory below it should be owned by root or admin, be in the group root
or administrators, and should only be writable by this user and group.
For Linux, these commands will ensure the privileges are correctly setup:
cd /etc/appweb
chown root . lib logs
chgrp root . lib logs
chmod 755 . lib logs
Dynamic ContentAppweb
supports an in-process method of dynamic content creation called Embedded Server Pages (ESP).
ESP will execute HTML pages with embedded code and scripts and process them 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.
Embedded Server PagesTo keep server-side ESP scripts private, you must have the ESP
handler configured to process the required script extensions or URL prefixes. If a script
extension is not configured, the static page handler may process the page and return the raw
script back to the user. As installed, Appweb defines the ".esp" and ".asp" extensions for ESP
pages.
Embedded Gateway InterfaceEGI forms are secure from file-based permission flaws
because they run in-process and access no files.
SSL ServersIf you configure
a SSL virtual server, remember to define a separate DocumentRoot if you want to only serve
private content to SSL users. Otherwise those pages will also be visible via the default
server.
AuthenticationIt is highly
recommended that you not use basic authentication and only use digest authentication. As
implemented in Appweb, digest authentication provides many safeguards against known exploits
including; man-in-the-middle attacks, client spoofing, and replay attacks.
SandboxingSandboxing is the
term applied to running Appweb in a confined environment. When embedding a HTTP server in an
application, the profile of user access is often well known. This 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. By default, Appweb has a relaxed set of defaults that will permit a wide range of
requests.
The sandbox directives can specify:
LimitBufferedBody
|
Maximum size of generated dynamic data |
LimitRequestBody
|
Maximum size of the incoming request body
|
LimitRequestFields
|
Maximum number of headers in the request
|
LimitRequestFieldSize
|
Maximum size of the request header
|
LimitUrl
|
Maximum size of a URL
|
SendBufferSize
|
Size of the TCP/IP buffer to use for requests
|
StartThreads
|
Number of threads to preallocate in the thread pool
|
ThreadLimit
|
Maximum number of threads to allocate on demand for the thread pool
|
ThreadStackSize
|
Size of the per-thread stack
|
Log FilesAppweb 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.
|
