NetLicensing Journal

In this next article in our ongoing series on the future for application developers, we now turn to applications which are commissioned and made for business. The stereotypical image of a businessman with both his suitcase and email-enabled phone hastiled checking, reading and replying whilst on the go.

In our recent article, we looked at the question of whether or not an increasingly saturated application market is leading towards an application ‘crash’. There is a strong argument to be made that developing for niche markets is the way forward if companies and developers are to be successful.

How to keep producing relevant software:

We have already looked at how applications which use external references to a browser can be vulnerable to attacks (see Unvalidated Redirects and Forwards). With Cross Site Request Forgery you are dealing specifically with an application which sends HTTP requests to the user’s browser, as a part of its day to day functionality. External URL requests are, as we have previously discussed, a risk because they take the user outside of the boundaries of the application. This means that the level of control which you as a developer have is immediately impeded. However, there are still a number of steps you can take to prevent cross site request forgery.

During the past month we’ve been focusing on improving NetLicensing, and today Labs64 team is pleased to announce the availability of NetLicensing version 2.0.

In the articles which we have already published on the topic of application security, there has been a recurring topic of proper authentication within the application. Applications are built in layers, with different degrees of access being granted to different users; depending upon whether their credentials have been correctly authenticated. Obviously the primary access to the application should be as secure as possible, with timeouts, secure password policies etc. This article will look at the need for secure references within the application.