Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: The CERT Oracle Secure Coding Standard for Java Date: Sat, 28 May 2011 09:07:31 -0400 Organization: A noiseless patient Spider Lines: 46 Message-ID: References: <899ac5cb-b1e4-44b1-8e27-e6385b4fdcdb@24g2000yqk.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 28 May 2011 13:08:51 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="BrOwaJANne849xlH+KPYjQ"; logging-data="30433"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18iQLeBrlGeKRqiLyU3pJG7" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:2Z+oVc+Btj7QClM0UvVLuy0NeXI= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4683 On 5/28/2011 3:42 AM, Nasser M. Abbasi wrote: > On 5/27/2011 10:44 AM, rCs wrote: >> The CERT Oracle Secure Coding Standard for Java has been completed and >> is now ready for >> https://www.securecoding.cert.org/confluence/display/java/The+CERT+Oracle+Secure+Coding+Standard+for+Java. >> >> >> The CERT Oracle Secure Coding Standard for Java provides rules for >> secure coding in the Java programming language. The goal of these >> rules is to eliminate insecure coding practices that can lead to >> exploitable vulnerabilities. >> >> To review, you can create an account on the wiki and then post >> comments to any of the pages, or respond directly to me. >> >> Thanks, >> rCs > > I thought Java was already secured? i.e. no buffer overflow > problems like with C, and the sandbox thing for applets and > all of that. I did not know that Java can be not secured before. Follow the link, read at least the introduction, and improve your understanding. > But, would it be not better, if the language can be defined > so that these remaining security holes that can make it not > secure be closed at the language definition level, instead of > having set of rules, that one need to print out and hang on > the wall to look at while coding? This way the compiler job > to spot them, not the programmer. Much better. "Security" is not a property of a language in isolation (nor of any tool in isolation), but only in the context of desired and undesired behaviors. The desires are not the tool's, but the user's. The compiler cannot read your mind, especially concerning matters you haven't thought about yet. Power saws these days usually have blade guards and other such security features to help their operators keep all their fingers close at, er, hand. But no saw, no matter how safe, will refuse to cut great gouges in the priceless antique table. -- Eric Sosman esosman@ieee-dot-org.invalid