web2ldap - Security

Some notes on security
<Download> <News> <Demo> <Related>
<Commercial> <Feedback> <FAQ>
<Features> <Installing> <Configuration> <Compability> <Security> <Changes> <Files> <Roadmap>

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


  • Don't use this for highly confidential data (as you should never provide such data over Internet)!
  • Note that every web application is a security risk. There's no warranty by the author of any kind!
  • Running under the control of Apache is still the most secure running-mode since modules like M2Crypto are not as thorougly tested as Apache and SSL implementation in web2ldap is still experimental.
  • It's highly recommended deploying SSL and client certificates for securing the LDAP access through this gateway!
  • Good news: web2ldap does not invoke any external program (e.g. via the os.system() or os.popen() functions).
  • 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.


  • 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.
  • Due to limitations in the python-ldap module it is unfortunately not possible to encrypt the LDAP connection with SSL/TLS protocol.
  • Only simple authentication is supported.

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 through the proxy.
  • Special HTML characters are converted to HTML representation (see function escapeHTML() in module cgiforms) 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. No credentials are stored at all!
    • 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.
    • Two-step behaviour for expired sessions:
      After this time an user is allowed to relogin and retry his last action by just entering the password/credential.
      After this time the session is silently deleted without notifying the user at all.

Page last modified: Monday, 30-Apr-2001 23:58:23 CEST, © by Michael Ströder <>