I don't really see this as two approaches. At one end of the spectrum, you can do security inside your code. But there are many underlying "sandboxes" that restrict what your code is able to do. Each of these may be configurable to be 'semi-permeable' for your app.
My opinion is people should locate the security where it's most effective and easiest to build, configure, maintain, and operate. For example, you could enforce access to local files in your code, in the VM, or in the OS. Where is best? Depends on what you're doing and your environment. The important point is that everyone involved understands the approach and that it's simple to verify. I'm confused about how your "fix the tools" approach is any different from a sandbox. Building APIs that prevent developers from making security mistakes is just the same. And there's another important use of sandboxes that I think you're ignoring. When you have to run code that you didn't develop, the end-user can use the sandbox to protect their underlying platform. It's a question of control. --Jeff > -----Original Message----- > From: Brian Eaton [mailto:[EMAIL PROTECTED] > Sent: Friday, May 26, 2006 10:54 AM > To: [EMAIL PROTECTED] > Cc: Dinis Cruz; Stephen de Vries; Secure Coding Mailing List; owasp- > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [WEB SECURITY] RE: [SC-L] Re: [WEB SECURITY] On sandboxes, > and why you should care > > On 5/26/06, Jeff Williams <[EMAIL PROTECTED]> wrote: > > > > Dinis Cruz wrote: > > > If you do accept that it is possible to build such sandboxes, then we > > > need to move to the next interesting discussion, which is the 'HOW' > > > > > > Namely, HOW can an environment be created where the development and > > > deployment of such Sandboxes makes business sense. > > > > It's the "business sense" part of this that's really difficult. It wouldn't > > be *that* hard to put sandbox enforcement into all libraries. If you want > > to protect against XSS, put a validation and encoding sandbox into > > HttpServletRequest. If you want to stop SQL injection, get rid of > > non-PreparedStatement and build in some control for direct references. > > Two distinct approaches to fixing software are described here. > > With one method, sandboxes, developers need to do a bunch of extra > work to define sandbox policies for their applications. Sandboxes > don't have a great track record because it is too much work to do them > properly. > > With the other method, better tools and APIs, developers do less work > and get better results. The reason buffer overflows are relatively > rare in web applications is because web applications aren't usually > written in C. They are written in high level languages that do bounds > checking automatically. XSS is endemic in web applications because > the tool sets encourage people to generate HTML on the fly. The > evidence is clear: fix the tools and you'll end up with more secure > apps. > > Sandboxes are best understood as band-aids on buggy, broken > applications. Band-aids have a place, but avoiding the errors in the > first place is more effective. > > Regards, > Brian _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
