Securing Web servers is hard work, as OWASP periodically reminds us. Of course, this applies to smart card web servers, regardless of the underlying technology. I received a comment from someone who noticed that some of the Java Card 3.0 Connected sample applications have really bad security. Basically, all the attacks from OWASP’s book that can apply will apply.

Of course, one can claim that a piece of sample code is here to show a very basic implementation, not a fully secure application. On the other hand, I often claim that security should be built in from the ground up in applications. Now, here are the problems noticed by Blaufish:

• Servlet does not validate data in doGet(). That’s really bad, of course. Any HTML injection will work at that stage. The problem is that solving this issue is far from simple. The libraries that provide adequate protection against attacks are actually rather large and/or require significant resources, unless of course we oversimplify them, resulting in strong restrictions.
• Servlet does not encode output in doGet(). That’s also bad, especially since nothing is done on input. The problem is the same as above.
• Servlet performs write upon GET, HTTP guidance violation. OK, this is typically due to sample code simplicity.
• Servlet does not implement anti-XSRF tokens. This is actually rather easy to do in Java Card, and we would expect all SCWS applications to actually include a random string in request in order to avoid XSRF forgeries.
• Database layer does not validate data. Combined with the absence of validation and encoding in doGet, this is of course unacceptable, since it would allow really terrible attacks. The issue is the same as for other validations, but a solution needs to be found.
• No user authentication/authorization/session model. Here, my first thought was that there were other opportunities to add security in this application, in particular in the Web descriptor. However, since the operations are specified as query parameters, things may not be that easy. Except that the application is so “stupid” that any access control would be very basic, most likely a binary decision.

So, what should we do? Including complex validation code in basic examples definitely isn’t the solution. However, mentioning that the application is a basic sample that doesn’t include the security measures required in any deployed application, regardless how simple, that could be done, and it may actually already be done. Also, we must recall that not all samples are that simple, and that some of them actually include some security (at least declarative security); we should make sure that there exists at least one example that include state-of-the-art security.

The real challenge, though, is to find appropriate countermeasures, i.e., countermeasures that will work on real applications, running on real cards. That means that they must protect against major attacks, while allowing most uses, and fitting in the card.

Another issue is to identify which attacks actually apply, especially in the limiting context of OMA SCWS, where the mobile phone is the only possible client of the servers. Obviously, some attacks are not a problem: for instance, no risk of denial-of-service attacks. It also reduces the impact of some attacks, because the owner of the phone is the likely victim of most attacks, and many such attacks need to be performed by the owner. A SCWS Web application will not be as exposed as a classical Web application. However, depending on the usage patterns, there is a residual risk, which needs to be identified and countered.

Possibly not a minor challenge. I am not too worried about the first applications; we’ll manage to get them right (well, if we think about security in the first place). But if SCWS spreads, we will have to define a systematic way of including this security, which could be more difficult. Let’s see what happens.

What you can read in this presentation is quite sad. There have been many discussions about portability issues for MIDP applications over different handsets, and these slides made me realize that the problems are just about the same for people developing mobile Web sites, even for very stupid issues.

Since SCWS primarily targets SIM cards, it means that these portability issues are going to creep in the SIM card. SIM Toolkit developers usually have many tales about the way in which handsets support SIM Toolkit in a variety of strange and unpredictable ways, but it seems that the situation is not getting any better as we move to another application model.

If we move in this presentation, we get to its core proposal, which is to use W3C widgets for mobile applications. And when we get there, the relationship with SCWS becomes completely different.

First, the issue that W3C widgets address concerns the flaky connections available on mobile networks (and in particular the sharing of bandwidth with people connected on the same cell). Naturally, SCWS also addresses the same issue, since a local Web server does not require any bandwidth.

Let’s look at this closer. If the two technologies address the same issues, they may actually be competing technologies. A W3C Widget is a small bundle including an HTML page with some additional content (JavaScript, images, …), and a descriptor. This is definitely something that Java Card 3.0 could do. Of course, the technologies are not equivalent, because Java Card 3.0 also provides the ability to locally generate content dynamically, and store data persistently.

The main competition between these two models is about the place where widgets should be stored. The “natural” place to store widgets is on the mobile, because that is what the people specifying W3C Widgets had in mind (widgets stored on the client). On the other hand, mobile operators may like the ability to push widgets to their users through their Java Card 3 SIM cards.

Enough for competition. One of the requirements from this presentation is the need for JavaScript Device APIs. Such APIs allow a Web application to access some features of the device, like the camera, the contacts, and many other things. Now, that could be interesting for Java Card 3. I can see a few interesting uses for pictures taken during the execution of a Java Card 3 application, or for accessing the contact list (that would actually be funny for the SIM to recover some access to the user’s contacts through this API).

A side effect of these Device APIs is that, since they provide an access to sensitive features, some security measures are required, such as a signature of the widgets or some interaction with the user when these widgets are installed. Then, as we have such signatures, it is tempting to extend the list of potentially sensitive things that become accessible. One of them would be to make mashups between a SIM-based application and outside application easier, by somehow allowing an exception to the “single origin” browser rule (possibly through a specific API).

There remains a number of issues to be addressed regarding widgets, including the security issue, but this approach sure is interesting, and I have the feeling that it is rather a step forward for client-side Web servers such as SCWS, even though it can also be seen as a potential competitor.

Even if LG is not talking about it, the news is still good, as it means that Smart Card Web Servers are not going the same way as NFC and USB-SIMs, waiting for years for handsets to support the technology. LG even wants to go further than a single product, as stated in the last interesting sentence of the press release:

Beginning in 2009, LG plans to have the SCWS feature available on most LG HSDPA handsets.

Of course, right now, we have to continue working with SCWS SIM card based on Java Card 2, becaues there is no existing Java Card 3.0 SIM card. So, if you want to see your SIM-based content displayed on a LG Renoir phone, you will need to write your site with byte arrays and other fun things. Good luck!