Preface

We heard cyber security incident daily, seems like a habit forming or it will be happened daily. We wasn’t gutted ( Feeling sad and unhappy) since we have already become insensitive!

Who’s the perpetrator?

The design limitation not only found on hardware (BIOS), OS (system kernel , dynamic link library and software driver). Besides, the critical risk sometimes found on application program design.  Since mobile phone become the technology world main stream in the market because of BYOD enable concept.May be you observe this factor earlier. Both personal computer and BYOD device looks has common criteria (not the security standard common criteria). The fact is that they are heavy duty to deploy of Java application. From technical point of view, the difference in between personal computer and BYOD device application platform might have minor things. For instance application cannot display on small size display screen. Web browser compatibility issue. Perhaps those problem enough to annoys application developers. However in regards of application infrastructure both personal computer and BYOD devices are sharing the similar application source. And such a way carry out a visible securiy bottle neck on application design. Yes, we select one of the bottle neck on software application development to discuss today. It is the API key, so I dubbed API key is the perpetrator.

What is API key?

With reference to Wikipedia (see below details for reference)

An application programming interface key (API key) is a code passed in by computer programs calling an application programming interface (API) to identify the calling program, its developer, or its user to the Web site.

API keys can be based on the universally unique identifier (UUID) system to ensure they will be unique to each user. The API key often acts as both a unique identifier and a secret token for authentication, and will generally have a set of access rights on the API associated with it.

Appendix i :

API key = a public unique identifier for your app.

Access token = another secret! But a new one is generated every time a new person installs your app. Each one is used for authentication of regular API calls to a particular shop.

API Key fundamental design weakness 

Kill chain – scenario A (Application program design weakness)

• User gets infected with malicious program
• Malicious program opens up /rest/config
• Malicious program navigates to / and takes the CSRF token from the cookie it receives
• Malicious program now has complete control over the REST POST interface

Kill chain – scenario B (system application software package (library) design weakness)

JSON Web Token (jwt) vulnerability includes the following authentication mechanism : node-jsonwebtoken, pyjwt, namshi/jose, php-jwt or jsjwt with asymmetric keys (RS256, RS384, RS512, ES256, ES384, ES512)

The original design of JSON Web Token structure contains 3 parts , a header, a payload, and a signature.  See below details for reference.

Prerequisite – require X509 Private/Public Key Pair to generate the digital signature.

The Base64-URL encoded representation of the Secure Header

The Base64-URL encoded representation of the Payload

The signature that is generated from the combined "payload.header"

Assembling all of these together as payload.header.signature

Below simple node.js code that uses the jsjws node module to create the JWS

var assert = require('assert');
var jsjws = require('jsjws');
var fs = require('fs');

var privKeyFile = fs.readFileSync('./dsig-key.pem');
console.log("privKeyFile: " + privKeyFile);
var priv_pem = jsjws.createPrivateKey(privKeyFile, 'changeit','utf8');
var pubCertFile = fs.readFileSync('./dsig-cert.pem');
console.log("pubKeyFile: " + pubCertFile);
var pub_pem = jsjws.X509.getPublicKeyFromCertPEM(pubCertFile.toString())

var header = { alg: 'RS256' };
console.log("Header: " + JSON.stringify(header));
var payload = { 'a':'b',
'c':'d',
'e': 1.0
};
console.log("Payload: " + JSON.stringify(payload));

var sig = new jsjws.JWS().generateJWSByKey(header, payload, priv_pem);
console.log("Signature: " + sig);
var jws = new jsjws.JWS();

assert(jws.verifyJWSByKey(sig, pub_pem, ['RS256']));
assert.deepEqual(jws.getParsedHeader(), header);
assert.equal(jws.getUnparsedPayload(), JSON.stringify(payload));

console.log("UnparsedHeader: " + jws.getUnparsedHeader());
console.log("UnparsedPayload: " + jws.getUnparsedPayload());

Found Critical vulnerabilities in JSON Web Token libraries (March 31, 2015)

A design limitation on library occurred, some libraries treated tokens signed with the none algorithm as a valid token with a verified signature. This is so called “none” algorithm.

Therefore hacker can create their own “signed” tokens with whatever payload they want, allowing arbitrary account access on some systems.

Remediation & Mitigation

It looks that the vulnerability found on library has security remediation today. As we know the vulnerabilities in JSON Web Token libraries can settle by latest version of software libraries. But how about the application program design weakness item?  As far as I know. Even though you are going to manage your API Keys with Java, Jersey, and Stormpath. The common standard on API Key management in the market more relies on the following solution.

1. Filter  (regular expression). As far as I know,  It requires the preventive control filtering function to avoid
2. Define full scope of authentication mechanism (something you have,something you know and something you are)

• Define authentication protocol
• Based on the authentication result object do the integrity check
• Check the token that received, and appropriately gives appropriate action (forbid or access).

Opinion

In regards of API key, authentication Token & XML language are hard to avoid the risks once they are working together. However it is hard to avoid in such operation manner in business world. But I would like to let this opportunities to urge software developer that JSON Web Tokens should be avoided in your application design.  If your design insists to adopt such methodology. You must re-confirm the data classification level in your local repository and business criteria. If both two domain subjects not in DCL 3,4 and not the critical business operation. May be it still a green light signal. If not it is better to find other alternative.