Securing Ajax Applications

Web Server Hardening

Now that we have a secure, stable, bastionized host to begin with we can look at the web server itself. First, you are going to have to decide which web server to use. Ubuntu came with Apache2—at least that is what was installed after I chose the install LAMP option—so, I am going to start there. But several web servers are available, some part of larger frameworks like application servers.

The following are some general guidelines to protecting web servers/traffic:

• Run SSL. Probably one of the best security things you could do is invest in a digital certificate (http://www.verisign.com) for your web server. In an age where Internet attacks are on the rise, it is hard to tell a secure site from an insecure one. SSL goes a long way toward solving that problem.

• Require that all cookies going to the client are marked secure.

• Authenticate users before initiating sessions.

• Do server monitoring.

• Read the logs.

• Validate fire integrity.

• Review web application for software flaws and vulnerabilities.

• Consider running web applications behind a web proxy server, which prevents requests from directly accessing the application. This creates a place where content filtering can be done before data reaches the application.

Now, let's look at the specific web servers and see what we can do to secure them.

Apache HTTP Server

The Apache HTTP Server is the most popular web server on the Internet, which helps explain why it comes as the default web server on so many systems. The Apache HTTP Server Project is an effort to develop and maintain an open source HTTP server for modern operating systems including Unix and Windows. The goal of this project is to provide a secure, efficient, and extensible server that provides HTTP services in sync with the current HTTP standards.

The following is a set of hardening guidelines for securing Apache:

1. The Apache process should run as its own user and not root.

2. Establish a group for web administration and allow that group to read/write configuration files and read the Apache log files:

   groupadd webadmin
   chgrp -R webadmin /etc/apache2
   chgrp -R webadmin /var/apache2
   chmod -R g+rw /etc/apache2
   chmod -R g+r /var/log/apache2
   usermod -G webadmin user1,user2

3. Establish a group for web development.

   groupadd webdev
   chmod -R g+r /etc/apache2
   chmod -R g+rw /var/apache2
   chmod -R g+r /var/log/apache2
   usermod -G user1,user2,user3,user4

4. Establish a group for compiling and other development.

   group development
   chgrp development 'which gcc' 'which cc'
   chmod 550 'which gcc' 'which cc'
   usermod -G development user1,user2

5. Disable any modules you are not using.

6. Manage .htaccess from within the httpd.conf file instead of .htaccess. In the server configuration file, put:

   <Directory />
   AllowOverride None
   </Directory>

7. Enable Mod_Security. This module intercepts request to the web server and validates them before processing. The filter can also be used on http response to trap information from being disclosed. (Note: enabling this module does have performance implications, but the security benefits far outweigh the performance impact for a web site with moderate web traffic.)

8. Enable Mod_dosevasive. This module restricts the amount of requests that can be placed during a given time period. (Note: enabling this module does have performance implications, but the security benefits far outweigh the performance impact for a web site with moderate web traffic.)

Security concerns

Protect server files by default

Inside the Apache configuration file (httpd.conf) have the following directory directive:

<Directory />
  <LimitExcept GET POST>
    Deny from all
  </LimitExcept>
  Order Allow,Deny
  Allow from all
  Options None
  AllowOverride None
</Directory>

<Directory /var/apache2/htdocs/>
  <LimitExcept GET POST>
    Deny from all
  </LimitExcept>
  Options -Indexes -FollowSymLinks -Multiviews -Includes
  Order Allow,Deny
  Allow from all
  AllowOverride None
</Directory>

Script aliasing

From a security perspective it is better to designate which directories can employ dynamic functionality or execute scripts. By using script aliases administrators can control which directories and resources will be allowed to execute scripts. If a site needs the ability to execute scripts this approach is preferred.

Server side includes (SSI)

Server side includes are directives found in HTML pages that Apache evaluates while serving a page. If SSIs are enabled they allow dynamic execution of content without having to initiate another CGI program.

Generally I recommend not using SSIs. There are better options for serving dynamic content. SSI is easy to implement but because of its flexibility hard to secure.

Tip

Users may still use <--#include virtual="..." --> to execute CGI scripts if these scripts are in directories designated by a ScriptAlias directive.

mod_security

mod_security is a web application firewall that is an Apache Web Server add-on module that provides intrusion detection, content filtering, and web-based attack protection. It is good at detecting and stopping many known web attacks, such as many SQL injection type attacks, cross-site scripting, directory traversal type attacks, and many more.

Tip

mod_security does come with a performance cost. Because the module must inspect web traffic going both to and from the web server it can cripple sites with high user loads. In most cases, however, the security benefits far outweigh the performance costs.

Installation

You can get the mod_security packages using apt:

apt-get install libapache2-mod-security
a2enmod mod-security
/etc/init.d/apache2 force-reload

The file /etc/httpd/conf.d/mod_security.conf should now exist.

Basic configuration

mod_security.conf contains an example mod_security configuration. The example configuration has a lot of stuff in it that we may not need, so I recommend trimming the file down a bit and starting with the basics:

<IfModule mod_security.c>
    # Turn the filtering engine On or Off
    SecFilterEngine On

    # Make sure that URL encoding is valid
    SecFilterCheckURLEncoding On

    # Unicode encoding check
    SecFilterCheckUnicodeEncoding Off

    # Only allow bytes from this range
    SecFilterForceByteRange 0 255

    # Only log actionable requests
    SecAuditEngine RelevantOnly

    # The name of the audit log file
    SecAuditLog /var/log/apache2/audit_log

    # Debug level set to a minimum
    SecFilterDebugLog /var/log/apache2/modsec_debug_log
    SecFilterDebugLevel 0

    # Should mod_security inspect POST payloads
    SecFilterScanPOST On

    # By default log and deny suspicious requests
    # with HTTP status 500
    SecFilterDefaultAction "deny,log,status:500"

    # Add custom secfilter rules here

</IfModule>

From here, we can look at what actions we can configure.

Actions

Table 4-1 lists the most important actions mod_security can apply to an event caught by the filtering ruleset.

Table 4-1. mod_security filtering rulesets

Action	Description
allow	Skip remaining rules and allow the matching request.
auditlog	Write request to the audit log.
chain	Chain the current rule with the rule that follows.
deny	Deny the request.
Exec	Execute (launch) an external script or process as a result of this request.
Log	Log the request (Apache error_log and audit log).
msg	Message that will appear in the log.
noauditlog	Do not log the match to the audit log.
nolog	Do not log the match to any log.
Pass	Proceed to next rule.
redirect	If request is denied then redirect to this URL.
status	Use the supplied status codes if a request is denied.

Now, we can configure a few basic rules specific to our environment that enable mod_security to protect our applications.

Filters

Let's say some of our applications pass parameters around that may end up in our MySql database. Let's also say we were lazy and did not positively validate those fields before trying to INSERT them into the database. Then, some wily hacker comes along and tries to perform a SQL injection attack.

So, how does this really work? With mod_security's filters we can write rules that look for these kinds of attacks:

SecFilter "drop[[:space:]]table"
SecFilter "select.+from"
SecFilter "insert[[:space:]]+into"

Resources

Ivan Ristic has provided a thorough primer on mod_security in his book Apache Security (O'Reilly). Go pick up a copy and have a look. I also highly recommend a visit to the site http://www.modsecurity.org if you intend on using mod_security. There you will find documentation, tools, and additional downloads.

PHP

PHP has grown from a set of tools that get web sites up and working fast to one of the most popular languages for web site development. The following are some recommendations for hardening web servers that use or support PHP.

Hardening guidelines

1. Apply all the Apache security hardening guidelines.

2. Disable allow_url_fopen in php.ini.

3. Using disable_functions, disable everything you are not using.

4. Disable enable_dl in php.ini.

5. Set error_reporting to E_STRICT.

6. Disable file_uploads from php.ini.

7. Enable log_errors and ensure the log files have restricted permissions.

8. Do not use or rely on magic_quotes_gpc for data escaping or encoding.

9. Set a memory_limit that PHP will consume. 8M is a good default.

10. Set a location for open_basedir.

Microsoft Internet Information Server (IIS)

Microsoft Internet Information Services (IIS) is an HTTP server that provides web application infrastructure for most versions of Windows.

In versions of IIS prior to 6.0, the server was not "locked down" by default. This open configuration, although flexible, was not very secure. Many unnecessary services were enabled by default. As threats to the server have increased so to has the need to harden the server. In these older versions of IIS, hardening the server is a manual process and often difficult to get right.

Lock down server

With IIS 6.0 administrators have more control over how, when, and what gets installed when installing the IIS server. Unlike previous versions, an out-of-the-box installation will result in an IIS server that accepts requests only for static files until configured to handle web applications plus sever timeouts, and other security policy settings are configured aggressively.

Secure configurations for web servers

Microsoft also provides a Security Configuration Wizard (SCW) that helps administrators through the configuration of the web server's security policy.

Hardening guidelines

1. Make sure that the system IIS is installed in a secured and hardened Windows environment. Additionally, make sure the server is configured to discourage Internet surfing and email use.

2. Web site resources, HTML files, images, CSS, and so on should be located on a nonsystem file partition.

3. The Parent Paths setting should be disabled.

4. Potentially dangerous virtual directories, including IISSamples, IISAdmin, IISHelp, and Scripts should all be disabled or removed.

5. The MSADC virtual directory should be secured or removed.

6. Include directories should not have Read Web permission.

7. No directories should allow anonymous access.

8. Only allow Script access when SSL is enabled.

9. Only allow Write access to a folder when SSL is enabled.

10. Disable FrontPage extensions (FPSE).

11. Disable WebDav.

12. Map all extensions not used by the IIS applications to 404.dll (.idq, .htw, .ida, .shtml, .shtm, .stm, .idc, .htr, .printer, and so on).

13. Disable all unnecessary ISAPI filters.

14. Access to IIS metabase (%systemroot%\system32\inetsrv\metabase.bin) should be restricted via NTFS file permissions.

15. IIS banner information should be restricted. (IP address in content location should be disabled.)

16. Make sure certificates are valid, up to date, and have not been revoked.

17. Use certificates appropriately. (For example, do not use web certificates for email.)

18. Protect resources with HttpForbiddenHandler.

19. Remove unused HttpModules.

20. Disable tracing (Machine.conf ).

21. Disable Debug Compilation (Machine.conf ).

22. Enable Code Access security.

23. Remove All Permissions from the local Intranet Zone.

24. Remove All Permissions from the Internet Zone.

25. Run the IISLockdown tool from Microsoft.

26. Filter HTTP requests using URLScan.

27. Secure or disable remote administration of the server.

28. Set a low session timeout (15 minutes).

29. Set account lockouts.

Security concerns

• Do not install the IIS server on a domain controller.

• Do not connect an IIS server to the Internet until it is fully hardened.

• Do not allow anyone to log on to the machine locally except for the administrator.