UPDATED ON 04/06/10: Additional comments about security requirements
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.