For all you web application developers, I’d like to briefly note the following stack trace I received from the American Express website while clicking around:
And here is the same trace in plain-text format:
JSPG0036E: Failed to find resource /cardcenter/common/interstitial.jsp
java.io.FileNotFoundException: JSPG0036E: Failed to find resource /cardcenter/common/interstitial.jsp
Most developers might say, “So what? You just clicked on a broken link somewhere. Go back and go about your business.”
And that’s exactly what I did, since I just wanted to pay a credit card bill. But what if “my business” had been to gather forensic information about potential American Express website vulnerabilities? A stack trace may look innocuous, but we can be almost certain that this HTTP request was handled by a Java servlet. It uses Java Server Pages (JSPs) for view templating, and the application appears to be running on IBM WebSphere. Not only this, but we have line numbers for each stack frame, and the CSS appears to be some form of default styling.
Large institutions such as AmEx tend to not upgrade to the latest versions of development libraries until a future interal release cycle where the new version(s) can be internally vetted, tested, QA’d and put through a due diligence process. (Or for older apps, dependencies might not be upgraded at all.) This makes stack traces extremely valuable to an attacker. Why? Because I can obtain all historical versions of technologies such as WebSphere, and map every specific call in the stack trace back to the code until I find the software versions where the line numbers match up. The attacker should at least be able to narrow down the software version numbers to a range, if not the specific release version. After gathering this information, the attacker may choose to fixate on the older packages, and consult databases of vulnerabilities in legacy software until a vulnerability is discovered.
Long story short: turn off the rendering of stack traces in public-facing production applications. They’re convenient for validation of production errors, yes, but you don’t know what they may reveal.
After a long confusing Ruby debate today at OpenRain on the merits of functional, Erlang-esque write-once-read-many variables, I’m going to step onto the podium and just say it… Ruby should get “final” or “const” variables in a similar semantic style to Java, except at runtime. Rather than ramble on for 12 paragraphs explaining exactly how this might work, read this fictitious Ruby code snippet instead. (Optional: Also check out the chapter on “final” in Hardcore Java.)
Final variables like this are really just an inline TDD mechanism.
Allowing local stack data to be constant provides no functional enhancements to the software, but alleviates the need for certain types of tests by using the compiler and/or runtime to assert certain memory is immutable. The “friend_best” method variant in the code snippet would obviously break most existing Ruby programs, but ups the bar for defensive programming by preventing many common bugs out-of-the-box while still providing support for traditional Ruby variables. At the very least we should have something like “friend_better”. Adding this information to the parse tree will also make it easier for IDEs to provide features more easily implemented for static languages.
TDD/BDD is in–no qualms about it–but we can make our code safer, cleaner and more concise by applying some of the lessons learned by our statically-typed language cousins over the last few decades.
Sometimes I think we’ll eventually run out of TLAs (three letter acronyms) in the Java space. Here’s a quick reference for the forgetful..
- ABB (Audio Building Block)
- API (Application Programming Interface)
- BCC (Bluetooth Control Center)
- BPWD (W3C Mobile Web Best Practices Working Group)
- CBS (Cell Broadcast Service)
- CDC (Connect Device Configuration)
- CLDC (Connected, Limited Device Configuration)
- CSS (Cascading Style Shee)
- CSS-MP (Cascading Style Sheet – Mobile Profile)
- DDC (Default Delivery Context)
- GCF (Generic Connection Framework)
- J2ME/JME (Java Micro Edition)
- JTWI (Java Technology for the Wireless Industry)
- JMF (Java Media Framework)
- JSR (Java Specification Request)
- JVM (Java Virtual Machine)
- MMAPI (Mobile Media API)
- OBEX (Object Exchange Protocol)
- OMA (Open Mobile Alliance)
- PAN (Personal Area Network)
- PDA (Personal Digital Assistant)
- PDAP (PDA Profile)
- PIM (Personal Information Management)
- MIDP (Mobile Information Device Profile)
- MMS (Multimedia Message Service)
- SMS (Short Message Service)
- SDD (Service Discovery Database)
- UAP (User Agent Profile)
- WAP (Wireless Application Protocol)
- WCSS (Wireless Cascading Style Sheet)
- WMA (Wireless Messaging API)
- WML (Wireless Markup Languge)
- WTK (The Sun Java Wireless Toolkit/J2ME Wireless Toolkit)
- XHTML-MP (XHTML Mobile Profile)
Only developers with hair should use JXTA, because those with bald or shaven heads wonâ€™t have anything to violently rip from their skulls while they develop with it. I have been, and continue to be excited by, JXTAâ€™s potential, but have been very disappointed at the pace at which a project progresses when using it. JXTAâ€™s capabilities, on the PowerPoint level, are impressive. It facilitates a great deal of networking features necessary for peer-to-peer operation and service discovery. So whatâ€™s my beef? A couple major areas off the top o’ me head..
There isn’t exactly a massive community using JXTA. There are limitless possibilities of the platform and a few significant projects that use it, but it’s not exactly a common-place technology. That’s ok. Communities need time to grow. But to build a better mousetrap, people must understand why yours is better, and how to use it properly. At first I suspected I had jumped into the system at a particularly odd moment, but most of the documentation Iâ€™ve read is either out of date, or, in the case of much of the code itself, completely missing. This may come as a surprise to the good folks at jxta.org who provide many links to JXTA articles, but as a developer new to the platform sitting down and getting started, youâ€™ll find yourself confused by deprecated and changed APIs without a clear understanding of the Right Way to do things. The – popular – books – are – long – outdated.
As an advocate of test-driven development, my application unit tests attempt to cover the interactions between multiple peers on the JXTA network. Doing so requires instantiating multiple cores within the same Java unit test process, and being able to reset them to initial states between test cases. Unfortunately, JXTA is designed as a singleton, which as we already know is not a friendly pattern to test-driven development. Couple this unfortunate design with the general difficulties of multi-threaded unit testing, and you’ll either be spending vast amount of time with your unit tests, or forgoing the complicated ones completely. Probably the latter. So whatâ€™s the solution? Iâ€™m not exactly sure, but Iâ€™ve started working on one.
Currently code named “Journeta”, that goal is to create a greatly simplified, zero-configuration-required peer discovery and communication Java library for “trusted” networks. No configuration files, hefty learning curve or even constructor arguments, but no security or over-the-internet functionality either. (At least at the library level.) While I haven’t been actively developing it this year, I started the project last year over at OpenRain, and anticipate releasing a build sometime this summer. Let me know if youâ€™re interested and Iâ€™ll ping you when we release a demo.