Tom HawtinThomas Hawtin's Weblog"Secrets Of The Masters" (allegedly)- December 29, 2006 Linux Sys-Con hava a new (Dec 2006) article listing 30 sample interview questions for Java "masters". So let's have a look at some of the more advanced ones... For senior-level developers: Yes, "senior-level" developers. Q21. What's the difference between a queue and a stack A. Stacks works by last-in-first-out rule (LIFO), while queues use the FIFO rule To be a pedant: If we are talking Java, java.util.Queue (capital Q) can be LIFO too. In fact it would take much to get Stack to...http://www.jroller.com/tackline/entry/secrets_of_the_masters_allegedly Intercepting events without broken glass.- December 21, 2006 The usual way of intercepting mouse events is with a glass pane. Other than being a bit clumsy and intrusive, there are many problems with glass panes to do with PL&F interference, D&D, etc. An alternative is to intercept the events as they leave the EventQueue. Applets and JNLP applications can push their own event queue. Applications started with -Djava.security.manager cannot. Further, overloading the method we need, dispatchEvent, prevents C&P working with the system clipboard..http://www.jroller.com/tackline/entry/intercepting_events_without_broken_glass Review: Java Security Guidelines by Gary McGraw and Ed Elten- December 17, 2006 This book, Securing Java, dates from 19981999, but that's quite modern for Java mobile code security. Section 1 of Chapter 7 "Java Security Guidelines: Developing and Using Java More Securely" presents 12 rules for writing security-critical Java code. These were also published in JavaWorld (but they do not permit linking to a sensible version of the article). Rule 1: Don't Depend on Initialization As far as I am aware, objects are recoverable even without completing constructors normally in...http://www.jroller.com/tackline/entry/review_java_security_guidelines_by Review: Sun's Java Code Security Guidelines- December 17, 2006 For many years this longstanding document appears to have represented the Sun's advice on secure mobile code. Below is a review of each individual point. The completeness as a whole, I leave to your imagination. Note at JavaONE May 2006 mention was made of updating the document. This has not yet happened. Static fields Yes, non-final public statics are bad. As are non-final protected statics (I still don't understand what they are supposed to imply). Also final publicprotected statics...http://www.jroller.com/tackline/entry/review_sun_s_java_code Security flaws in untrusted code- December 15, 2006 Surely not possible. At worst sensitive data is sent in the clear. Well, if you try really hard, you can introduce flaws. The approach presented here works in a shared execution environment with an appropriate security manager, such as the Java Plug-in. What you will need to do is create a thread whilst running on a system thread. The security manager will assign this the applet context thread group, rather than the current thread group. The finalizer thread is the obvious example of a system..http://www.jroller.com/tackline/entry/security_flaws_in_untrusted_code Mixed certification: An example- December 14, 2006 As a change from being all theoretical, here is a practical way to exploit naively signed code. Instead of picking on a kosher signature, I have used an unverified signature (anyway, the colours nicely match the warm and friendly Ubuntu look). The JDIC FileExplorer demo happens to be the first signed appletapplication I deliberately looked for security flaws in. Rather conveniently, FileExplorer clears the security manager. If we can get our code to run after this, then the sandbox is...http://www.jroller.com/tackline/entry/mixed_certification_an_example Mixing trusted and untrusted code- December 11, 2006 I had thought Sun had realised mixing trusted and untrusted code was BAD. JNLP forbids it. The Java PlugIn has quietly added the restriction, apparently without telling anyone. However, it appears that any code can be treated like an extension. So in order to mix all an attacker needs to do is pretend some of the code is an optional package. He or she can now make merry constructing stacks of trusted objects. Have you effectively audited your signed codehttp://www.jroller.com/tackline/entry/mixing_trusted_and_untrusted_code Who should care about mobile code security- December 10, 2006 Mobile code security is a solved problem in Java, right There are situations in which code must be secure. In particular code that is intended to be, or will ever be, used in: the Java library extensions containers for untrusted code (for instance, some web servers) libraries shared between contexts within secure containers trusted contexts within secure containers (for instance, signed applets) The first three bullets should, I hope, be pretty obvious. Shared libraries are slightly...http://www.jroller.com/tackline/entry/who_should_care_about_mobile The curse of inheritance- December 3, 2006 We all know that implementation inheritance leads to fragility. If your class needs to be secure, then that goes double. Are you intending to override every inherited method What if someone adds another, but doesn't bother to fix your class That happened with Java WebStart. FileOutputStream was subclassed to prevent annoyance code filling up your disk. After WebStart was written, NIO was added to Java. To support NIO, FileOuputStream adds extra methods. Annoying code can cast the supplied...http://www.jroller.com/tackline/entry/the_curse_of_inheritance |