On Fri, 23 Jun 2006, Crispin Cowan wrote: > nabiy@xxxxxxxxxxx wrote: > > Trying to make the language 'safe' won't fix it because the language > > is not the problem. The real problem is the way PHP is presented to > > most new developers. > > > > * snip * > > > That is a fascinating perspective. > > Web developers who work with static content (HTML and images, etc.) is > pretty secure: the security threat amounts to Apache configuration > (directory browsing and htpasswd stuff) and it is pretty difficult for > an attacker to corrupt static content by way of the content. > > Dynamic content, while not inherently dangerous, becomes dangerous when > you hand the web developer a Turing-complete language. Suddenly the > exact behavior of the web site under arbitrary input becomes > undecidable. Programmers (mostly) know this. Security developers > (should) know this. Web artists may have just been introduced to > programming to get their web site to be dynamic. > This is true, of course, even with basic shell scripts -- give a user CGI or the ability to launch any sort of program that can access data outside of the user's own directory, and you already have potential security problems. It's not even necessarily confined to running an application; it could be as simple as allowing Server Side Includes, permitting something like: <!--#include file="/etc/passwd"--> > There are two possible approaches to fixing this. One, as nabiy > suggests, is to change how PHP is presented to web developers. Label it > as a chain saw, and point out that chain saws don't know the difference > between "log" and "leg" :) > CGI-bin routines and SSIs are not chainsaws, but they might qualify at least as hedge trimmers... Full-blown tools like perl and PHP certainly do. And for exatly that reason, my feeling is that the ability to tap into these ought to not be granted by default -- it's almost as if you should need to have legitimately obtained a driver's license of sorts to be able to operate equipment like this on a public highway. > The other is to contrive a language that is both sufficient for dynamic > web content development, and also *not* Turing-complete. I have no idea > what such a language might look like, or even whether the intersection > of these two requirements is the null set. > The problems with granting any sort of CGI permissions to the user automatically gives out carte blanche to employing a huge variety of scripts or executables, as others have pointed out. So instead of restricting things on the language level, another option is to create a specific wrapper that will launch a specific user app, and only that specific user app. It requires that trust is granted to the specific routine and of course, it should be launched with careful consideration as to what UID it runs as. Apparmor, I presume, would fall under this category. There are also a number of Apache options that deal with running jailed or restricted code. However, even with restrictions on what can be run, argument passing still remains a big issue, especially if dynamic content is desired. Furthermore, what features you trust someone with may not be universal for any given installation. Undoubtedly, someone will come up with a justification for needing more than one is initially willing to grant, and so a power struggle is likely to ensue over who gets what priviledges. This, in turn, quickly could escalate into a hopelessly complex administrative issue, requiring constant monitoring of potential security issues on an individual basis. This is a very fuzzy area and I agree with Dr. Cowan that there are no simple answers. The crux of the matter is that once you let the users start employing any dynamic languages, it becomes potentially a huge time sink, either because of the time and effort needed to administer the environment or the resources needed to deal with security issues that are bound to result because of it. Freedom has its price.
