[mod_python] security issues

Thought of some more.

12. 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.

13. If you use PythonAutoReload, realise that modules are simply reloaded
on top of the already loaded modules. This is in part shown in 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.

Graham

Graham Dumpleton wrote ..
> Also:
> 
> 10. Especially if using mod_python.publisher, 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
>    http://issues.apache.org/jira/browse/MODPYTHON-10
>    http://issues.apache.org/jira/browse/MODPYTHON-11
> 
> 11. 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.
> 
> 
> Graham
> 
> On 02/02/2005, at 2:44 AM, Jorey Bump wrote:
> 
> > Lula Dog wrote:
> >
> >> I cannot find anything related to the python security 
> >> configuration/installation...Any hints?
> >> I just want to know if there are some security guidelines during the
> >> installation/configuration of Python on Unix systems...
> >> Any help would be very much appreciate....
> >
> > 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:
> >
> > 1. Store sensitive data in modules outside of the DocumentRoot of your
> > site. This prevents modules from being exposed if mod_python isn't 
> > running.
> >
> > 2. 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.
> >
> > 3. Use the FilesMatch directive to disallow access to important types
> > of files, such as *.pyc, *.pyo, *~, etc.
> >
> > 4. 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 (_foo = "secret 
> > word").
> >
> > 5. 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.
> >
> > 6. 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*.
> >
> > 7. 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.
> >
> > 8. Learn about Python's mechanisms to restrict what gets exported by
> a 
> > module.
> >
> > 9. If your database and application are on the same machine, don't let
> > the database listen on a port exposed to the Internet.
> >
> > That's all I can think right now, hope it helps.
> >
> > _______________________________________________
> > Mod_python mailing list
> > Mod_python at modpython.org
> > http://mailman.modpython.org/mailman/listinfo/mod_python
> 
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python