2012/3/6 Ángel González <keis...@gmail.com> > On 06/03/12 14:04, Adam Jon Richardson wrote: > > The sandbox I'm considering would only impact the ability to directly > call... > It's not that easy. The internal functions could be splitted to > safe/unsafe (according > tosome definition, which would itself be a controversial one)
Yes, perhaps controversial, but using an objective criterion like purity would aid the effort. > but all > functions defined > outside would be injection candidates, too. The idea I put forth would only deal with internal functions. Frameworks and CMS's would still be on-the-hook to validate incoming data and escape data according to context for all of the functions that they expose to the plugin/library. And this would still be very beneficial. As framework developer, I can validate the inputs coming into my API hooks and escape the outputs according to context. However, when plugin developers can call the internal functions and circumvent my protections, this is a more difficult issue to solve en masse. > Suppose you modified the > function > hash table to store if it's a limited function or it should be run with > high privileges. > I'm not promoting a privilege-based system of high and low privileges. Rather, I'm posing the possibility of limiting the access of included code to internal functions/objects. > Now, you need to audit the whole framework so that no can be tricked > into doing more > things than it should, if called from low-privilege code. > Which is pretty hard when that code could be corrupting your variables. > For instance, a safe framework function to perform database queries, > could become > unsafe by changing the db configuration (usually stored on globals), > allowing connections > to arbitrary servers. > It would be the responsibility of the framework or CMS or application to protect against this type of attack (which they do quite well.) When you can force a plugin to work through your API, you can take appropriate measures. When the plugin can avoid working through, say, a file API that protects against misuse by using the internal file functions, this is a much more difficult issue to mitigate. > Or a malicious plugin could register a class with the same name as a > framework one, before > the autoloader loads the right one, and have it used by privileged code. > > PHP is not designed to use it that way, so unless there is an high level > way to do it, it's probably > impossible to do right. Maybe you can perform a full global replacement > when calling > untrusted code. That might work. > Javascript wasn't "designed this way", either. However, tools like Secure EcmaScript go a long way towards protecting against the attacks mashups typically must prevent by protecting/limiting the environment: http://code.google.com/p/es-lab/wiki/SecureEcmaScript http://www.infoq.com/presentations/Secure-Mashups-in-ECMAScript-5 Thanks for the feedback, Angel. Adam
