On 8 Jun 2007, at 02:23, Steven M. Christey wrote: > > More modern languages advertise security but aren't necessarily > catch-alls.
At the same time, the improvements in security made by managed code (e.g. the JRE and .NET runtimes) for example, should not be understated. The fact that apps written in these languages are not susceptible to buffer overflow issues is a HUGE improvement. And for this particular vulnerability these languages are effectively catch- alls. (As long as all your code is managed and the runtime implementation itself doesn't contain BO's). The fine grained access control model of the Java runtime (I guess .NET has the same thing?) is also a big win. This is not an add on framework, but is built right into the language. As Ben and Robert have pointed out, we're likely to see similar improvements when developers make more use of frameworks for implementing application tiers. It's a lot harder to introduce XSS issues when using modern MVC frameworks (e.g. .NET's, JSF, WebWork) than cobling a view layer together using JSPs and servlets. It would still be possible for developers to introduce vulnerabilities when using these frameworks, but it's a lot more difficult. > I remember one developer telling me how his application used > Ruby on Rails, so he was confident he was secure, but it didn't > stop his > app from having an obvious XSS in core functionality. It's ironic that RoR is well known for it's policy of preferring sensible defaults instead of extensive configuration, yet you have to explicitly perform HTML encoding of data included in a web page. > PHP is an excellent example, because it's clearly lowered the bar for > programming and has many features that are outright dangerous, > where it's > understandable how the careless/clueless programmer could have > introduced > the issue. Web programming in general, come to think of it. There are also examples of languages/frameworks that get it right, such as JBoss Seam where both SQL injection and XSS are difficult to introduce by default. It's easier to build secure applications when the building blocks themselves provide security by default. Developers will adopt frameworks because they make programming easier - if these frameworks also prevent common security vulnerabilities then that's a big win for more secure applications. Where security pro's can help out is in pointing out poor security defaults in frameworks and getting the owners to change them. Change once, benefit everywhere. regards, Stephen "the glass is half full" de Vries _______________________________________________ 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 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
