Encrypting Node.js Session Cookies In A ColdFusion.js Application
In my ColdFusion.js framework (a port of the ColdFusion Application Framework to Node.js), session cookies and session tokens are implicitly managed by the underlying framework. You can, however, tell the ColdFusion.js framework not to set client cookies. In that case, the ColdFusion.js framework will associate the session based on the "this.sessionID" value that you provide in your Application.js configuration module. It then becomes your responsibility to make sure that each request provides a valid sessionID. This can be great if you need to encrypt your session cookies for security audits that view default session identifiers as too predictable (and therefore more easily exploited).
By default, the ColdFusion.js application framework creates a cookie, "sessionID." This cookie is automatically sent to the browser and is used on each subsequent request in order to associate the incoming request with the appropriate server-side session. If, however, you turn off the setClientCookies property in your Application.js configuration:
this.setClientCookies = false;
... then the ColdFusion.js application framework will not create any session cookies on your behalf. At that point, it is left up to you as the programmer to find a way to provide an alternate means of session identification using the "this.sessionID" key. In this demo, we're going to look at setting up our own encrypted cookie and then decrypting it on each request in order to populate the sessionID property.
Application.js
// Define the factory object for Application.js. Since each incoming
// request has to define a new instance of the Application.js, we
// have to get around the module-based caching. This gives every
// request the opportunity to re-define the settings (this is a good
// thing - and a very powerful thing).
module.exports = function( request, response ){
// Define the application settings.
this.name = "ColdFusion.js Manual Cookie Demo";
this.applicationTimeout = (2 * 60);
this.sessionManagement = true;
this.sessionTimeout = (1 * 20);
// We are asking the ColdFusion.js framework NOT to
// automatically set the session cookies. This means it
// becomes our responsability to explicitly store a cookie
// in the onSessionStart() event handler and then create a
// this-scoped sessionID with each request.
this.setClientCookies = false;
// I am the unique sessionID that can be manually set in the
// case that the user wants to explicitly manage their own
// session.
this.sessionID = null;
// ------------------------------------------------------ //
// ------------------------------------------------------ //
// Since we are setting our own secret, encrypted sessionID
// instead of asking ColdFusion.js to create it, it is now our
// responsability to decrypt that cookie on each request so that
// ColdFusion.js knows what we're doing.
var secretKey = null;
// Get the secret cookie and see if it exists.
if (secretKey = request.cookies.get( "secretKey" )){
// We now have to "decrypt" our secret cookie in order to
// make the sessionID available.
secretKey = secretKey.replace(
new RegExp( "^BLAM-|-BLAM$", "g" ),
""
);
// Place the decrypted key back into the Application.js
// instance so that ColdFusion.js knows how to associate the
// incoming request with the right session.
this.sessionID = secretKey;
// Log our sessionID crypto conversion.
console.log( "IN >> " + request.cookies.get( "secretKey" ) );
console.log( "SessionID >> " + this.sessionID );
}
// ------------------------------------------------------ //
// ------------------------------------------------------ //
// I initialize the session.
this.onSessionStart = function( request, response, callback ){
// Set our "encrypted" cookie since we don't want people
// to see our sessionID.
//
// NOTE: I don't actually know how to use Node.js' crypto
// library yet; so, I am using encrypt in the silliest
// possible meaning of the term.
response.cookies.set(
"secretKey",
("BLAM-" + request.session.getSessionID() + "-BLAM")
);
// Store out hitcount.
request.session.set( "hitCount", 0 );
// Return out so the framework knows the event is over.
return( callback() );
};
// I process the request.
this.onRequest = function( request, response ){
// Increment our hit count.
request.session.hitCount++;
// Set the content type.
response.setHeader( "content-type", "text/html" );
// Write out some content.
response.end(
"<h1>ColdFusion.js On Node.js</h1>" +
"<p>Hit count: " + request.session.hitCount + ".</p>"
);
};
};
As you can see, we are turning of the implicit cookie handling. Then, in the onSessionStart() event handler, which gets fired whenever a session gets created, we are manually creating a "secretKey" cookie. In the code, I say that we are "encrypting" the cookie value; but, since I know nothing about the Node.js crypto library, the best I could do at this time was some silly obfuscation.
Once the secretKey cookie has been manually created, we then need to decrypt it on each request. In the pseudo constructor (what ColdFusion refers to as the area in the object but outside the methods), we are taking our secretKey cookie, decrypting it, and putting it in the "this.sessionID" configuration property. Once the Application.js object has been fully initialized, the underlying ColdFusion.js application framework will then look at this configuration-based session identifier when it tries to associate the correct server-side session.
From a security standpoint, the problem with frameworks is that they are predictable. If you are building a Node.js application, it therefore becomes absolutely critical that your application framework provides a way for you to manually manage your session cookies. The ColdFusion application framework provides this for the ColdFusion developers; and now, the ColdFusion.js application framework provides this same functionality for Node.js developers.
Want to use code from this post? Check out the license.
Reader Comments