jQuery in Action, 2nd edition*
The moose likes Security and the fly likes Java Coding Guidelines: Java finger-wagging Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Java Coding Guidelines: Java finger-wagging" Watch "Java Coding Guidelines: Java finger-wagging" New topic
Author

Java Coding Guidelines: Java finger-wagging

Yvette Schat
Ranch Hand

Joined: Dec 05, 2011
Posts: 64
Hello again,

Java is regularly picked on when it comes to security. In some interesting security
podcasts like 'Security Now' for example this is often the case...

Obviously this comes up in discussions amongst colleagues. As I love Java can you
give me some arguments to counter this finger-wagging?

Best regards,

Yvette
David Svoboda
Author
Greenhorn

Joined: Oct 21, 2013
Posts: 13
    
    5

Yvette:

I wish Java's current security problem was called Java's sandbox problem instead. Java's security sandbox makes it possible to have trusted code and untrusted Java code in the same program. More generally, it let people run untrusted Java applets on the web. Applets that could show you dancing bunnies, but couldn't touch your files. Or your network. People trusted Java's security sandbox for 15 years before it was widely exploited. This sandbox problem is the source of most of Java's current troubles.

It's a really arcane problem, too. No other language allows trusted & untrusted code to run in the same program. Even programs with plug-in architectures, such as Firefox, assume you only install & run a plugin if you trust it. So developers aren't used to having untrusted code in their programming environment.

But if your Java program does not use this sandbox problem, these troubles don't affect you. More to the point, if you don't permit untrusted code to run in your porgram, these troubles don't affect you. So if you're writing a desktop application or Android app, these troubles don't affect you. They only affect Web applet & servlet developers.

So to run Java safely, you should assume your Java program does not permit untrusted Java code to run alongside its trusted code. If you write code in any other language you already assume this.


[Java Coding Guidelines] and [The CERT Oracle Secure Coding Standard for Java ] are from the [CERT Secure Coding Initiative]
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41601
    
  55
David Svoboda wrote:They only affect Web applet & servlet developers.

I think this needs a bit of elaboration, mentioning applets and servlets as if they faced the same security issues is misleading IMO. Applets are Java code from an unknown source run on my desktop (effectively), that's why the proper functioning of the sandbox is so critical: because code of unknown provenance otherwise has access to my files.

Web apps, on the other hand, are generally written and run by the same organization, so even in the case of a broken sandbox it would be my code that could access my files - not a big deal. (Unless we're talking about shared hosting, where person X's web app runs on person Y's server along with the other folks' web apps. That is a different case, in which the sandbox once again becomes critical. But these two cases need to be differentiated.)


Ping & DNS - my free Android networking tools app
David Svoboda
Author
Greenhorn

Joined: Oct 21, 2013
Posts: 13
    
    5

Thanks, Ulf. One of the problems with applets is that (until recently) there was no way to indicate that you trust the applet you are running. Oracle's recent updates to Java have provided users with the ability to trust (or not trust) a Web applet. This does place extra burden on the users, but eases the burden on certain applets....in particular applets created by the user's company.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61095
    
  66

I too am interested in an answer to Ulf's questions on servlets. Could you address those?


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Dean Sutherland
Author
Greenhorn

Joined: Oct 22, 2013
Posts: 3
    
    5

Ulf Dittmer wrote:
David Svoboda wrote:They only affect Web applet & servlet developers.

I think this needs a bit of elaboration, mentioning applets and servlets as if they faced the same security issues is misleading IMO. Applets are Java code from an unknown source run on my desktop (effectively), that's why the proper functioning of the sandbox is so critical: because code of unknown provenance otherwise has access to my files.

Web apps, on the other hand, are generally written and run by the same organization, so even in the case of a broken sandbox it would be my code that could access my files - not a big deal. (Unless we're talking about shared hosting, where person X's web app runs on person Y's server along with the other folks' web apps. That is a different case, in which the sandbox once again becomes critical. But these two cases need to be differentiated.)


We've seen a number of issues regarding shared hosting of web apps. See, for example CVE-2009-0783; detailed explanation on our wiki at SEC03-J. As Ulf says, that brings sandbox issues back into play. However, even web apps written and run by a single organization may require proper functioning of the sandbox. This is most likely to be an issue for public-facing web apps that provide services to users outside the organization; it's rarely an issue for purely internal web apps. Exceptions include applications in national security agencies (think Secret and Top Secret data) where even internal users should be prevented from seeing data for which they lack clearance.

My personal bottom line for responding to the "Java finger-wagging" is that Java is significantly more secure than most other languages. That said, successful support for mixing trusted and untrusted code (e.g., sandboxing) is really hard; most other languages don't even try! And some popular use-cases for Java—executing downloaded applets and shared hosting of web-apps—fundamentally depend on getting the sandboxing exactly right. That's where the headline vulnerabilities have appeared.
David Svoboda
Author
Greenhorn

Joined: Oct 21, 2013
Posts: 13
    
    5

Apache Tomcat is a "servlet container". Which is to say, it provides a framework that enables servlets to be accessed on the web. Tomcat has several mechanisms to allow a servlet to be deployed, including remote uploading. If you're authorized, you can package up your servlet, go to a Tomcat form, and upload it, and your servlet is now live.

Tomcat uses Java's SecurityManager to protect the servlets from itself and from each other. Since this is the same SecurityManager used by applets, it has the same vulnerabilities. A malicious servlet could bypass the sandbox and run Java code with the same privileges as Tomcat itself. Crashing Tomcat would therefore be easy, and a suitably advanced malicious servlet could probably corrupt Tomcat to misbehave, perhaps tricking users of other servlets into submitting sensitive info (such as passwords).

The remaining question is how an attacker gets a malicious servlet onto a running Tomcat instance. Tomcat does have various protection mechanisms to decide who gets to deploy servlets, and more are provided by its operating platform. Clearly deploying a malicious applet is easier than deploying a malicious servlet, because your attacker has to convince some Tomcat instance to deploy their malicious servlet.

I'm gonna stop here because I've reached the limits of my Tomcat knowledge
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41601
    
  55
A production servlet container will typically not have any means of deploying web apps short of access to the command line and the file system. That is to say, any "manager
Web app" or similar would responsibly be turned off. So an attack on this is in an entirely different ball park than a rogue applet. That's why I said mentioning both in the same sentence needs qualification.
Dhruv Mohindra
Author
Greenhorn

Joined: Dec 08, 2009
Posts: 11
    
    5
Hi Ulf,

The distinction between the risk for an applet and servlet is definitely worth noting as you explained.

Ulf Dittmer wrote:
David Svoboda wrote:They only affect Web applet & servlet developers.

Web apps, on the other hand, are generally written and run by the same organization, so even in the case of a broken sandbox it would be my code that could access my files - not a big deal.


Although it sounds overkill to sandbox web apps, it can provide an additional layer of defense. For example, in the scenario you cite above, a path traversal vulnerability in code could compromise the file system contents unless the application's IO access is specifically restricted to a folder or file through the use of a Java security policy and security manager. A hole in the sand-boxing mechanism would be detrimental in such cases.



You know what I did last summer - Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Java Coding Guidelines: Java finger-wagging