web2ldap - Security
Author: Michael Ströder <michael@stroeder.com>
Description: web2ldap: Some notes on security
Keywords: LDAP LDAPv2 LDAPv3 subschema gateway Python python-ldap Directory userCertificate PKI LDIF DSML

Take the time to think first about your personal security requirements before running it!

## General

- You should carefully think about whether to provide highly confidential data over a networked service!
- Note that in principle every web application is a security risk. There's no warranty by the author of any kind!
- It's highly recommended deploying SSL and client certificates for securing the LDAP access through this gateway!
- Running under the control of Apache or another web server with SSL/TLS support is the only option to deploy SSL/TLS for securing the HTTP traffic. Stand-alone mode does not provide SSL/TLS support yet.
- Good news: web2ldap does not invoke any external program.
- Again good news: Because this is Open Source software you can audit the code. Feel free to do so and please report any problems if you find some.

## LDAP

- User passwords are not stored on disk or passed around unless you turn on debug logging.
- Note that the security options of web2ldap are not intended for providing fine access control to the directory data itself. You have to rely on the access control configured on your LDAP-host based on the bind DN. web2ldap binds to a LDAP-host with a bind-DN given by the user so that all server-side access control is in effect.
- Securing connections with LDAP over SSL or StartTLS extended operations is possible and highly recommended.
- Simple authentication (simple bind) and SASL bind is supported. Which SASL mechs are available depends on the build of your local client and SASL libs and the LDAP server's config.
- In opposite to many commercial products the group administration feature avoids security problems with concurrent administration and multi-valued member attributes of group entries by simply adding / removing single entries to / from groups instead of replacing all the member values.

## Web Security

- The environment variables for SSL data is specific for mod_ssl (preferred) or ApacheSSL (automatically used fallback option).
- All HTTP-headers have expire date set to current time to avoid security problems with browsers and proxies caching secret data. But be aware that some browsers/proxies ignore this and are caching all data anyway. One solution to avoid caching by proxies is to use a SSL-enabled web server because the web client uses the CONNECT-method of HTTP to go through the proxy.
- Special HTML characters are escaped to HTML representation to address the problems described in CERT Advisory CA-2000-02 - Malicious HTML Tags Embedded in Client Web Requests. This is maybe not an overall solution for this problem.
- Since version 0.9.0 URLs are not directly hyper-linked anymore. The URL points to the new urlredirect command which creates a HTML page with <meta http-equiv="refresh" content="0;..>". This avoids that the browser sends the currently viewed URL as Referer-URL which could reveal the session ID to an attacker.
- Since version 0.9.0 a server-side session database is maintained in memory accessible for all threads holding active LDAPObject instances. Credentials are stored in this memory object to enable automatic reconnects.
- Environment vars which are assumed to be constant throughout web sessions with the same ID are cross-checked when restoring a session to reduce the risk of session-hijacking.
- Sessions are expired sessions after a configurable amount of time. The session object is deleted.
- The following HTTP headers are always sent to avoid security/privacy problems:

  `X-Content-Type-Options: nosniff` | Switch off MIME-type guessing in MS IE 8+
  `X-XSS-Protection: 0` | Cross-Site Scripting Protection for MS IE
  `X-DNS-Prefetch-Control: off` | Switch off DNS prefetching
  `Strict-Transport-Security: max-age=15768000 ; includeSubDomains` | Enforce use of HTTPS at browser-side, but only sent when application was accessed via HTTPS (see RFC 6797)
  `X-Frame-Options: DENY` | Deny use of frames completely to avoid click-jacking (see The X-Frame-Options response header)