Most competent web developers have learned a thing or two about how to handle cross-site scripting and cross-site request forgery, the two main attack vectors for compromising the front end of a web application. These attacks take advantage of the complexity of modern web browsers and some of the idiosyncracies of how they function in the presence of content and scripts from a multitude of mutually mistrustful origins. Likewise, smartphone platforms are complex and must handle the safe coexistence of many apps with varying levels of trust and permissions, and they have some quirks of their own that present challenges for security. But since smartphones are a newer and younger technology, the kinds of security vulnerabilities present on them are much less well understood than the analogous web vulnerabilities. In this post we’ll take a look at an attack vector that often comes up on Android, namely intent spoofing, and discuss how to write apps that are secure from it.

We’re strong believers in testing of all sorts. Unit testing ensures that each of your classes and functions does what you expect, in particular at edge cases. Functional tests provide a check that entire systems work from a user point of view. Thanks to test frameworks like RSpec, JUnit, and Jasmine, unit tests are usually easy to create and run, since they depend upon nothing beyond the component being tested. While there are similar tools for creating functional tests (namely, Selenium for testing webapps), running the test can be much more complicated if you have multiple parts to your application.

At Palomino Labs, we recently completed a project that involved two main pieces: a webapp written in Rails and a data storage application in Java. In our scenario, a portion of the webapp’s functionality depended upon being able to communicate with the running Java app. In the development environment, this is a minor nuisance, requiring the developer to have the Java application running. Running the test automatically using Jenkins was a bigger problem, and since we know that automated testing is integral to catching regressions quickly, the problem needed to be solved. One option would be to have a long-running version of the Java service available to the Jenkins box, but that would far from ideal because we want to make sure that the versions of the Java and Rails projects that are used for testing stay in sync with each other. Instead, we have Jenkins start and stop a fresh, up-to-date instance of the Java service for every test run.

We created whichinstance.com a while ago to make it easier to decide which EC2 pricing option to use. Since then, we’ve gotten some questions on how to use it most effectively. To clarify its usage, I’ll walk through a couple of examples.

First generation Standard Medium instance, 100% utilization, 8 months

Hypothetical scenario: continuous integration box for a medium-term project (8 months). Since it’s a CI box for your hardworking global team, it needs to be running 24/7.

Java has no shortage of XML libraries and APIs: common ones like DOM, SAX, StAX, and JAXB, plus more esoteric ones like XOM, VTD-XML, Castor, etc. Of the more low-level XML tools (as opposed to data binding or other high-level functionality), the most common ones are DOM, SAX, and StAX, and this article explains how to use StAX effectively with StaxMate.

Between DOM, SAX, and StAX, why would one use StAX? DOM loads the entire document into memory and constructs a tree. It’s easy to navigate the tree however you wish, but having the whole document be RAM-resident is impractical with larger documents. SAX is a streaming parser, so it doesn’t have the memory usage problems that DOM does, but it’s awkward to use for many XML parsing tasks. StAX is a newer API that provides a more convenient API than SAX while delivering competitive performance.

Though StAX is easier to use than SAX, it could be better, which is where StaxMate fits in. StaxMate is a library that uses a StAX parser under the hood to get closer to the goal of DOM-like ease of use.

Contrived Example

There’s a sample project on GitHub. We’ll walk through the xml and the code step by step to show what’s going on. Try running the unit tests (with mvn clean install) and make sure everything passes.

The XML this code parses describes animals and vegetables and the various ways in which one may eat them. The XML is rather strange, but this is intentional so that different types of parsing tasks can be demonstrated.

Encryption is one of the more obtuse things that we do as programmers, perhaps appropriately so. Regardless of the language, search results are guaranteed to provide a myriad of different strategies, each describing different methods, many of which are subtly flawed, subverting their security goals. As is Java’s nature, performing encryption requires more programmatic steps than higher level languages, increasing the difficulty for those using encryption in their application.

Security Context

First, let’s take a look at what we’re going to do here. This post covers symmetric encryption, wherein a single key is used for encryption and decryption. In such a system there is a single thing, the encryption key, that must be kept secret and shared between anyone wanting to encrypt or decrypt data. In our example, we are also using a message authentication code (MAC), which requires its own key that must be secret & shared. Pieces of information like these are appropriately called shared secrets.

The MAC ensures that the outputs of our encryption (namely the ciphertext and initialization vector) have not been altered. It is theoretically possible to alter the initialization vector (IV) and ciphertext in concert to change the message without knowing the secret key. Additionally, either of those pieces could be manipulated so as to cause a fault when they are fed into the decryption system, causing an unexpected exception in your decryption system.