[mod_python] Mod_python Security

Another one, an important one at that.

7. Be aware that a security hole was found in mod_python. Unfortunately,
I can't seem to find the proper security advisory for it on mod_python
site. Only reference seems to be:

  http://www.modpython.org/3.1.4.html

I could be blind, but I would have thought it would have been important
to keep the notice on the main page.

If using 2.X stream, ensure you are using 2.7.11 or make sure your
distribution has patched 2.7.10 if that is what they are using.

If using 3.X stream. ensure you are using 3.1.4 or make sure your
distribution has patched 3.0.X or 3.1.3 if that is what they are using.

Graham
  
Graham Dumpleton wrote ..
> Some more.
> 
> 1. If using mod_python.psp and you have PythonDebug enabled
> the source code for your PSP pages can be visible by virtue of
> putting an underscore on the end of the extension. Eg. ".psp_".
> 
> It is thus a good idea not to have PyhthonDebug 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
> you own client machine in some way.
> 
> 2. If Apache has write access to directories, it can drop ".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, may have to block access to ".pyo" files as
> well.
> 
> 3. PythonDebug in general can reveal stack traces to a client when
> something goes wrong. In worst case, this may reveal secret information.
> 
> 4. 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.
> 
> 5. 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>
> 
> 6. If writing a custom handler, if wanting to return 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.
> 
> That is all I can think of for now. Sorry if some of it makes no sense,
> am in a rush.
> 
> Graham
> 
> On 03/03/2006, at 12:54 AM, Nicolas Lehuen wrote:
> 
> > There's an important rule :
> >
> > If you use the publisher, everything which is defined in a published
> > module is generally accessible from the web, except if its name begins
> > with an underscore.
> >
> > For example :
> >
> > # index.py
> > # BAD !
> > secret_password = "foobar"
> >
> > def index(req,password):
> >     if password != secret_password:
> >         return util.redirect(req,'/rejected.html')
> >     else:
> >         return "Welcome !"
> >
> > Your secret password in accessible through
> > http://my_server/my_folder/index.py/secret_password
> >
> > To make sure it won't be accessed, rename secret_password to  
> > _secret_password.
> >
> > There are exceptions to this "everything is accessible" rule, namely
> > imported modules, new-styles classes and built-in functions cannot be
> > traversed nor published. This prevents basic leaks like being able to
> > call sys.exit() from any published module that imports sys. Those
> > rules are specified in the lib/python/mod_python/publisher.py file, if
> > you are curious.
> >
> > But in any case, be aware that any string defined in a published
> > module is accessible unless its name is prefixed by an underscore,
> > which includes your precious database password.
> >
> > Regards,
> > Nicolas
> >
> > 2006/3/2, Mike Looijmans <nlv11281 at natlab.research.philips.com>:
> >> As with any server-side scripting, there's:
> >>
> >> - Cross-site scripting
> >> - Code injection
> >> - SQL injection
> >>
> >> But that's typically 'your' fault...
> >>
> >> Mike Looijmans
> >> Philips Natlab / Topic Automation
> >>
> >>
> >> marinus van aswegen wrote:
> >>> Hi
> >>>
> >>> I'd like to publish my page but I'm not sure what security issues
> >>> mod_python typically face.
> >>> Any recommendations?
> >>>
> >>>
> >>> Regards
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> ----
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >
> > _______________________________________________
> > 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