What's the next tech problem to be solved in software security?

[stephen at twisteddelight.org (Stephen de Vries)]

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