Secure Web Servers
Securing applications that are accessible to the Internet is not a trivial task. It is not as simple as enabling SSL or avoiding running as "root", although these are both important ingredients. Most HTTP servers have become more secure by a painful process of flaw detection and discovery. While it is no guarantee, developing a HTTP server to be secure by design in the first place, is easier than trying to engineer security in after the fact. Creating a secure embedded web server is even more difficult as it must be done without increasing memory footprint or damaging performance.
Secure Run-Time Environment
Mbedthis has approached the problem by designing in security before the first line of code was written. With the benefit of hindsight and having previously developed web servers with millions of deployments, the developers deeply understood the nature of the security threats that are common today. The foundation of AppWeb is a secure, portable runtime that helps trap one of the most common causes of security breaches: buffer overflows. This coupled with an effective multi-layered defence, enables AppWeb to be one of the most secure web servers available.
This document outlines some of the issues and offers tips to help you secure your application using the Mbedthis AppWeb product. More detailed help is available in the AppWeb product documentation.
Mbedthis AppWeb has a multi-layered approach to security. Some of the key elements are:
Mbedthis Portable Runtime (MPR)
AppWeb has been designed to be secure from the foundation by using the Mbedthis Portable Runtime (MPR). The MPR is a cross-platform layer that permits over 97% of the AppWeb code to be portable. It includes a safe string and buffer handling module to help the eliminate buffer overflows that have plagued so many products recently. It also warns when any unsafe (traditional) C API functions are used.
SandboxingThe AppWeb HTTP server closely controls its use of system resources via a technique known as "sandboxing". This means running the web-server within tightly controlled limits so that script errors or web server bugs will not compromise system operation.
AppWeb can be configured to:
- Preallocate memory and not grow beyond predefined memory limits
- Reject requests that are too large
- Reject URLs that are too long
- Run single-threaded or use a pool of reusable threads to service requests
- Be run by a designated user account or user group
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. AppWeb has also been hardened against several common denial of service attacks.
Some of the sandbox configuration directives are:
SSL and Authentication
AppWeb supports validation of the server and the clients identities via the use of the Secure Sockets Layer and SSL certificates. Several SSL providers are supported.
It 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.
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.
Security Enhancement ServiceEven 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 AppWeb 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. AppWeb also supports running in a dedicated account to minimize the its priviliges.
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. Your scripts will not be readable by users and users will only see the generated content.
|
