[Mod_python Wiki] Update of "SecurityConsiderations" by JimGallacher

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Mod_python Wiki" for change notification.

The following page has been changed by JimGallacher:
http://wiki.apache.org/mod_python/SecurityConsiderations

New page:
#format wiki
#language en

= Mod_python Security Considerations =

Many of the same security issues that apply to other embedded 
interpreters apply to mod_python. Here are some brief descriptions. 
Rather than list the solutions in detail, use them as a basis to 
search the mailing list or web:

  * Store sensitive data in modules outside of the `DocumentRoot` of your
  site. This prevents modules from being exposed if mod_python isn't 
  running.

  * Because the embedded interpreter runs applications as the apache 
  user, all other applications may have access to the same files. This
  can have serious implications in a multiuser environment, and applies
  to PHP, SSI, CGI, etc., as well.

  * Avoid any kind of dependency on the PATH environment variable. It
  can easily be changed by other applications, causing your own to fail.
  If you must call system programs, declare the full path explicitly, 
  '''always'''.

  * Debugging information can be essential when developing an 
  application. Take pains to ensure that error messages don't reveal 
  sensitive data if they are returned to the browser. Review your code,
  and use try/except statements to catch errors when appropriate.

  * Learn about Python's mechanisms to restrict what gets exported by
  a module.

  * If your database and application are on the same machine, don't let
  the database listen on a port exposed to the Internet.

  * Understand the quirks of mod_python.publisher if you use it as a 
  handler. For example, add a leading underscore to objects if you do 
  not want them to be directly accessible via HTTP. (4)

  {{{
  _foo = "secret word"
  }}}                      

  * If using mod_python.publisher and the legacy importer 
  `PythonOption mod_python.` (or mod_python version < 3.3), 
  don't use the same name 
  for Python code files (module names) in multiple places. This is 
  because there are bugs in its implementation which can cause cross 
  contamination of modules, the loading of the wrong module and other 
  issues. See: [http://issues.apache.org/jira/browse/MODPYTHON-9 MODPYTHON-9]
  [http://issues.apache.org/jira/browse/MODPYTHON-10 MODPYTHON-10]
  [http://issues.apache.org/jira/browse/MODPYTHON-11 MODPYTHON-11]

  * If you use `PythonAutoReload`, realise that modules are simply reloaded
  on top of the already loaded modules. This is in part shown in the
  [http://issues.apache.org/jira/browse/MODPYTHON-11 MODPYTHON-11]
  bug report. It is mentioned here as a separate item because it means that if
  you rename a variable/function or remove it, that doesn't actually mean it is
  no longer accessible. The only way to guarantee that old variables/functions
  are no longer accessible is to restart Apache. Thus, if you heed (4) and rename
  variables to have a leading underscore, make sure you restart Apache at the
  same time.

  * If multiple people share the same web server, use `PythonInterpreter`
  to assign your area of the web site its own instance of the Python 
  interpreter. This isn't fool proof as another user could do the same 
  thing and use the same name. When working though, it will keep your 
  stuff separate from others and avoid them being able to more easily see
  and fiddle with the internals of your running application.
   
  * When using the mod_python.psp handler with `PythonDebug On` the source code
  for your PSP pages can be visible by virtue of putting an underscore on
  the end of the extension. You need to add the `.psp_` extension to your
  `AddHandler` configuration directive to turn on this feature. 

  {{{
  AddHandler mod_python .psp .psp_
  PythonHandler mod_python.psp
  PythonDebug On
  }}}

  It is thus a good idea not to have `PythonDebug` enabled for production
  and/or public web site if using mod_python.psp. If you really need
  `PythonDebug` to be on, only enable it for requests coming from your own
  client machine in some way.

  * If Apache has write access to directories, it can write `.pyc` files into 
  the directories for modules loaded. This extension isn't generally 
  protected and people can download the ".pyc" files and potentially work
  out what your code is. Use something like:

  {{{
  <Files *.pyc>
  deny from all
  </Files>
  }}}

  Depending on platform, you may have to block access to `.pyo` files as well.

  {{{
  <Files *.pyo>
  deny from all
  </Files>
  }}}

  * Use the `FilesMatch` directive to disallow access to important types
  of files, such as `*.pyc, *.pyo, *~`, etc.

  * Turn off automatic directory indexing for Apache on directories which
  use mod_python. This is generally applicable to any web site, but potentially
  more so for mod_python if you forget to do (3). Thus don't use "Indexes"
  option.


  * If using an extension such as ".html" with `AddHandler` to map to handler 
  code in actual directory, ensure you block access to ".py" extension
  if need be.

  {{{
  <Files *.py>
  deny from all
  </Files>
  }}}

  * Don't store backup files where they can be accessed via HTTP. 
  Honestly, I'm sure I could gather about a thousand db passwords in a
  day if I simply created a bot that crawled dynamically driven sites 
  and appended `~` to every file name it finds.

  * `PythonDebug` in general can reveal stack traces to a client when 
  something goes wrong. In the worst case, this may reveal secret information.

  * Try to avoid putting source code in actual directories visible to Apache.
  Especially do not put sensitive information in such files. 
  The reason here is that it only takes one mistake in Apache configuration
  and all your code would be visible.

  * When writing a custom handler and returning apache.DECLINED,
  make sure you understand what it does. Specifically, it will cause
  the builtin default Apache handler to still run, which will serve up
  static files. Like above, you may need to deny access to certain files 
  as a result.

----
CategorySecurity