Re: Java: the next platform-independent target

[Jim Manico <jim.manico () owasp org>]

> PHP interpreter itself, and the occasional issues in Perl, and don't forget some of the tidbits in ASP.Net, maybe all 
> those should be tossed out as well, and we should all move back to C. ;-)

I think the deprecation of these technologies for an enterprise is a wise idea. :) How can a large enterprise use PHP 
or ASP for security-critical applications with a straight face? Let's move forward to Ruby on Rails, Enterprise Java, 
.NET and other modern frameworks that are more mature from a security centric POV. 

I have no problem with server-side Java, especially when using a modern security framework like Spring Security or 
(wait for it) ESAPI. But client-side Java? Flash? There are a few large organizations who have banned both from their 
clients and they are more secure for it.

-Jim Manico
http://manico.net

On Oct 21, 2010, at 10:58 PM, "Steven M. Christey" <coley () linus mitre org> wrote:

> PHP interpreter itself, and the occasional issues in Perl, and don't forget some of the tidbits in ASP.Net, maybe all 
> those should be tossed out as well, and we should all move back to C. ;-)
_______________________________________________
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.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________