|
James Paige
jamesp at westcoastaerospace.com
Thu Mar 2 16:54:43 EST 2006
These security hints are good stuff to have all in one place. I have edited together a list based on this thread and posted it on the mod_python FAQ at http://www.modpython.org/FAQ/faqw.py?req=all#3.28 --- James Paige Graham Dumpleton wrote: > 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 > _______________________________________________ > Mod_python mailing list > Mod_python at modpython.org > http://mailman.modpython.org/mailman/listinfo/mod_python >
|