Security Considerations

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

Updating Appweb
Sandboxing
Appweb User Account
File Permissions
Chroot Jail
Securing SSL
Authentication
Log Files
High Profile Threats
Common Security Threats
Frameworks

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 any vulnerabilities.

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. Limits should be set as low as possible while still permitting all valid requests and workloads.

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.

Appweb can monitor sandbox limits and trigger defensive responses if access is outside defined norms. See the Denial of Service section for more details.

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 number of simultaneous clients
LimitConnections	Maximum number of network connections. Note a client can open many network connections. A browser session will typically open 4-6 connections.
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:

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
LimitPacket	Pipeline maximum packet size for queues and stages
LimitProcesses	Maximum number of simultaneous CGI processes the server will start
LimitRequestBody	Maximum size of the incoming request body. Does not include file upload size.
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. A single worker may service many requests as Appweb will typically not block when serving a request. Workers are assigned to service network events and are then returned to a worker pool to service the next event.

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

Chroot Jail

One of the best forms of isolation for the server is to run inside a chroot jail. A chroot jail is when an application changes its root directory to be isolated from the real file system root directory. Any access then to files outside the jail is protected and impossible. Appweb supports chroot jails via the chroot directive and via the appweb --chroot command line option.

See also the Chroot Sample for a working example.

Securing SSL

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.

Cipher Selection

It is important to select a sufficiently long key length and strong cipher to protect SSL communications. It is recommended to use the AES cipher and avoid the older RC4 cipher suite. See the section below regarding Common Security Threats for threats against the RC4 ciphers.

SSL Forms

A common practice is to use HTTP for regular communications and to post login forms using SSL. However, this approach is flawed. The web form itself must be served using SSL as well as the URL receiving the login information. This prevents attackers injecting code into the form and hijacking login credentials.

For more information regarding SSL, please read:

Authentication

It is important to adequately secure all passwords stored at the server. Simply hashing the passwords with MD5 is now insufficient as MD5 and other "fast" hashing techniques can be quickly compromised by dedicated password cracking and hashing tools.

Appweb includes the blowfish cipher as an alternative that is more secure than MD5. The Blowfish cipher is especially well suited for password hashing partly. Partly because it is slow, it does not easily succumb to brute-force cracking.

If you wish to use the Digest authentication scheme, unfortunately you cannot use blowfish as the browser uses MD5 to encrypt the password before transmitting over the wire. This and other shortcomings of Digest authentication should encourage you to select other schemes. A better alternative is Basic authentication over SSL using blowfish to encrypt the passwords. Alternatively, use web form authentication with blowfish for password storage.

If using a web page for users to submit their credentials, it is strongly recommended that you use SSL for both the web form page and for the request validating the user credentials.

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.

Common Security Threats

This section details some common security threats and issues and the steps you can take to mitigate them.

Server Information Disclosure

HTTP responses often disclose information that an attacker can use to refine their attack. At a minimum, too much information enables the attack to proceed faster. Appweb includes a stealth directive that suppresses unnecessary information. Here is a typical HTTP response from Appweb

HTTP/1.1 200 OK
Content-Type: text/html
Server: Embedthis-http
Date: Thu, 15 Aug 2014 22:10:25 GMT
ETag: "cf4ce71-54-51c64a0b"
Content-Length: 84
Last-Modified: Sun, 23 Jun 2014 01:06:19 GMT
Connection: close
Accept-Ranges: bytes

Note that by default, Appweb does not disclose the web server version number in HTTP headers.

Stealth on

HTTP/1.1 200 OK
Content-Type: text/html
Date: Thu, 15 Aug 2014 22:11:46 GMT
ETag: "cf4ce71-54-51c64a0b"
Content-Length: 84
Last-Modified: Sun, 23 Jun 2014 01:06:19 GMT
Connection: close
Accept-Ranges: bytes

See that the Stealth directive has suppressed the Server header altogether. Attackers will need to work a little harder to know what kind of web server is responding to their requests — they may move onto another target.

Session Hijacking

Cookies are used to identify authenticated user sessions. As such, they are a prized piece of information by attackers. The HTTP Set-Cookie response header has an option to prevent client side scripts from ascertaining the session cookie value. This can greatly reduce the risk of session hijacking via cross-site scripting.

SessionCookie invisible

This directive Appweb to append the "httpOnly" value to the Set-Cookie response so the cookie will only be accessible to HTTP requests.

Set-Cookie: key=value; httpOnly

Mixed Transports

Is is a bad idea to mix secure and non-secure content in one page. This means a web page should be totally served by HTTP or by HTTPS but not mix transports on one page. The reason is that a page served by HTTP can be compromised and the guarantee of HTTPS and that green-browser https logo is diminished if the form page from which the user enters there data is not 100% trust-worthy.

Appweb provides a directive to enable a "Strict-Transport-Security" HTTP response header. This instructs the browser that all connections thereafter must only request over HTTPS. The specified age limit is in seconds. To enable this, use the following directive:

Require secure age=31536000

Denial of Service

Denial of service attacks can be difficult to detect and defend against. However, Embedded devices typically have a well defined, understood and anticipated work load. Unlike enterprise system, which have highly variable work loads, embedded systems typically serve a specific purpose with known clients that follow a more predictable access pattern. This allows an embedded system to define a range of operation that is considered "normal" and to trigger alerts and defenses if access is outside of this "normal" operation.

Appweb provides a Monitor and Defending framework that can detect many denial of service attacks. The defensive policies can alert and mitigate the attack and help maintain service. It is recommended that all systems consider this framework.

Cross Site Scripting

Cross-site vulnerabilities have ballooned over recent years. Unfortunately, there is no, single complete cure. However, Appweb supports the Content Security Policy (CSP) scheme that can go a long way to reduce the exposure. It does this by exactly specifying and restricting what cross-site access is permitted.

The following Appweb directive enables the Content Security Policy and restricts all access to the origin site. This is a good starting point.

Header set Content-Security-Policy default-src 'self'

See An introduction to Content Security Policy for more information.

For Microsoft IE, there is another step specific for IE that is useful. The following Appweb directive invokes some additional IE cross site protections.

Header set X-XSS-Protection 1; mode=block

Cross Site Sharing

Cross origin sharing is often required when using XMLHttp (Ajax) requests to communicate with another server. Cross Origin Resource Sharing (CORS) is a mechanism that allows scripts to make XMLHttp requests to another domain different from that which served the web page. This relaxes the same-origin policy of the browser, but in a controlled manner.

The Appweb CrossOrigin directive defines:

CrossOrigin origin=http://www.google.com credentials=yes age=3000

Hidden Frames

Hidden frames may be inserted by attackers to provide a launch-pad for running malicious scripts. Denying the ability to run frames can close of this attack vector.

The following Appweb directive will prevent frames or iframes from running in the web page.

Header set X-Frame-Options deny

High Profile Threats

There have been several high profile exploits that pose specific risks and have captured media attention. These are addressed specifically below with details on how to mitigate their effects.

Crime Exploit

The Crime Security Exploit attacks and exploits leakage of information due to the varying effectiveness of TLS compression.

Access to intercept and redirect client communications
Ability to initiate requests from the client
Encrypted communications SSL/TLS
TLS level compression

By default, Appweb does not use TLS with TLS compression and is thus not vulnerable to this exploit. If you are using OpenSSL, the OpenSSL SSL_COMP_add_compression_method will enable TLS compression, so it is important not to use this OpenSSL API.

Breach Exploit

The Breach exploit is a variant of the Crime exploit. It attacks and discovers private server information, such as CSRF tokens, by observing the compression of HTTP responses over SSL. This exploit requires the following to be effective:

Access to intercept and redirect client communications
Ability to initiate requests from the client
Encrypted communications SSL/TLS
Server-side encryption of dynamic responses
Unmodified inclusion in the response body of client specified query or form data

Appweb does not dynamically compress response content and so is not vulnerable to this exploit.

Beast Exploit

The Beast Security Exploit attacks block ciphers used by TLS to access encrypted packets. This exploit requires the following to be effective:

Use of TLS 1.0. This exploit has been addressed in TLS 1.1 and later.
Ability to position attacker as man-in-the-middle between server and client
Encrypted communications SSL/TLS
Using a block cipher.

Notes:

OpenSSL 0.9.6d and later are not vulnerable.
Appweb 3.3 and later have shipped with fixed OpenSSL libraries.
Using RC4 will mitigate the attack if upgrading OpenSSL is not feasible, however this cipher is vulnerable to the Luck 13 exploit described below.

Lucky 13 Exploit

The Lucky 13 exploit attacks TLS by using varying padding for block ciphers.

This exploit requires the following to be effective:

Ability to position attacker as man-in-the-middle between server and client
Encrypted communications SSL/TLS
Using a block cipher.
Use of the RC4 cipher.

Notes:

Mitigate by not using an RC4 cipher
RC4 was not the default cipher in any Appweb release

Documented Vulnerabilities

Appweb documents discovered security errors in its GitHub issue database at

https://github.com/embedthis/appweb-doc/issues/?state=open

Specific issue reports are created for all confirmed or erroneous security reports that receive a CVE classification. You can search for specific CVE numbers or see all via:

https://github.com/embedthis/appweb-doc/search?q=CVE-&type=Issues

Unfortunately some security researchers publish poorly diagnosed security alerts and sometimes do not contact the vendor for confirmation of the report. Consequently there exist some security CVE reports which are bogus. Appweb creates parallel CVE issues in the Appweb GitHub issue database to comment on these reports and provide accurate resolution information.

Other Security References

Some of these articles may provide good background regarding security web servers.

Frameworks

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.

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.

Appweb Secure By Default

Appweb is designed to be secure by default. This means that the default configuration enables security best-practices to limit cross-site-scripting vulnerabilities. It also implies a fairly restrictive security sandbox. This default configuration may be a little too restrictive for your application. In that case, you can easily remove or override these defaults by the relevant Appweb directives.

Appweb uses the following built-in configuration for the default route.

Header set X-XSS-Protection         "1; mode=block"
Header set X-Frame-Options          "deny"
Header set X-Content-Type-Options   "nosniff"
SessionCookie           invisible
Stealth                 on
InactivityTimeout       30secs
RequestParseTimeout     5sec
RequestTimeout          5mins
SessionTimeout          5mins
LimitConnections        50
LimitProcesses          10
LimitRequestsPerClient  20
LimitRequestBody        128K
LimitRequestForm        128K
LimitUpload             unlimited
LimitUri                512
LimitWebSockets         25
LimitWebSocketsPacket   8K
LimitWebSocketsFrame    4K
LimitWorkers            5

The default Content Security Policy header is set to only permit content loaded from the server running appweb. It also bans inline scripts as these are vulnerable to inline script injection. See An Introduction to Content Security Policy for more information.

You can override these directives globally in the main section of appweb.conf or locally in a specific route. (Except for LimitProcesses which always applies globally). You can remove the default security headers via:

Header remove X-XSS-Protection
Header remove X-Frame-Options
Header remove X-Content-Type-Options

Other directives worth considering are:

Chroot "."
Defense deny REMEDY=ban STATUS=406 MESSAGE="Client banned" PERIOD=10mins
Monitor "NotFoundErrors > 190" 5sec deny
Monitor "RequestsPerClient > 200" 5sec deny