Monday, August 31, 2009

Preventing Buffer Overflow Attacks

Is your website resilient enough to withstand a buffer overflow attack? A buffer overflow attack is actually one of the simpler attacks a malicious user may attempt. Imagine the following scenario. You have a public facing web page that allows unauthorized users to submit data. A malicious user probes your site to see if you have exposed this vulnerability. If your site is at risk, it may only take minutes for the user to bring your site down if they employ a botnet attack.

The Attack

  • The simplest attack method is for malicious users to throw overloading (2GB - 8GB) amounts of data in a text field in hopes of crashing the server due to out of memory errors.


The Prevention

  • Bounds checking on the server-side is the most effective solution for preventing buffer overflows. For example, if you are using Spring's annotation-based validation this is all you would need:

    /**
    *
    * Spring's annotation reference documentation
    * Configuration setup example
    */
    public class Student {

    @NotBlank
    @Length(max = 50)
    private String firstName;

    @Length(min = 1, max = 50)
    private String lastName;

    }


    HTML's maxlength attribute is NOT sufficient:
    <input type="text" name="firstName" maxlength="50" />
    This is not secure because there are tools that will enable users to bypass this HTML tier of validation. You must perform max length validation on the server-side as in the example above.
  • Leverage the bulkhead stability pattern to decouple your authenticated business critical applications from your publicly exposed (more vulnerable) applications. The goal of this pattern is to preserve the stability for a particular group of customers. Most software attacks are targeted at publicly available web sites. You should leverage this pattern if you want to help preserve the stability of your authenticated users during an attack on your publicly available sites.
  • Prefer to keep public data out of session. This simple solution will help preserve memory if a user attempts a buffer overflow attack.

Friday, July 31, 2009

JavaScript Singletons

JavaScript singletons are relatively simple to create. With two additional characters you can define your object as a singleton. I'll show how this is accomplished in a moment. In my prior JavaScript post I talked about why the module pattern was preferred for creating objects. Those objects were prototype-based and multiple instances were allowed. The following examples illustrate the preferred way to create singletons with the Module pattern. This should be your preferred creational pattern for creating JavaScript singletons.

Singleton Pattern Example #1:

/*
* Singleton counter example.
*/

var mySingletonCounter = function() {

/* private, static variables */
var count = 0;

return {
/* public methods */
increment: function (inc) {
alert('Adding ' + inc + ' to count.');
count += inc;
},

getCount: function() {
alert('The current count is ' + count);
return count;
}
};
}(); // <- These two parentheses define the object as a singleton. It assigns the result of invoking this function to mySingletonCounter.


To exercise the singleton, the button below will execute the following code:

mySingletonCounter.increment(2); mySingletonCounter.getCount();
Run Singleton Counter



Singleton Pattern Example #2:

/*
* Singleton data access example.
*/

var mySingletonData = function() {

/* private, static variables */
var data = {
1: "Harry Potter and the Philosopher's Stone",
2: "Harry Potter and the Chamber of Secrets",
3: "Harry Potter and the Prisoner of Azkaban"
};

return {
/* public methods */
getData: function() {
return data;
}
};
}();


Reference the singleton object in the following manner:

mySingletonData.getData()[2];
Run Singleton Data



Advantages:

  • It is extremely simple to declare a JavaScript object as a singleton. More dynamic languages are focusing on simplicity. For example, Groovy has recently provided the @Singleton transformation to simplify Singleton creation.
  • Improved run-time performance vs the prototype-based creational pattern.
  • You still leverage all the advantages that the module pattern provides.

Saturday, June 27, 2009

Agile: A requirements change is a competitive advantage

At what point in the lifecycle should requirements be locked down?
  1. Before development begins
  2. Never
  3. Somewhere in between

Most developers will immediately choose "Before development begins" for simplicity. However, if you work in an agile environment that responds well to change then there are many advantages to "Never".

Advantages of Changing Requirements

  • Changing requirements will improve the product and should give you a competitive advantage.
  • Changing requirements will evaluate the efficiencies of your development, QA, and deployment processes. Highly effective or agile teams will deliver the new requirement relatively pain-free.
  • Changing requirements encourage automation throughout the lifecycle. The important factor here is that it encourages automation across all departments (development, QA, deployment). The following attributes must exist within each department for this strategy to be successful:

    • Development:
      • Automated JUnit tests - frequent changes must be tested efficiently.
      • Continuous Integration - frequent changes require stable environments.
      • Code reviews - This knowledge transfer session will give your team the flexibility of having anyone work any task more efficiently.

    • QA:
      • Automated regression tests - frequent changes must be tested efficiently.

    • Deployment:
      • Automated deployment scripts - simplify and more accurately deploy the changed release modules.

  • Software must be delivered faster so the customer's can identify the change points sooner in the lifecycle. The goal is to deliver testable software quicker. How many of you deliver testable code after iteration one? How many of you have customer demos of working software after iteration one? The goal is to identify changes sooner in the lifecycle and this will help minimize the risk of failing to meet your production delivery date.

Disadvantages of Changing Requirements

  • Changing requirements may delay the project. This is where the debate typically begins. However, if you initially plan for some percentage of change you should be fine. Identifying change early in the lifecycle will also help remedy the impact.

The Hybrid Example

Which auto makers were most successful with their hybrid initiatives? It was the automakers that adopted lean/agile practices many years ago. The automakers that did not change soon enough are now scrambling to recover. Changing requirements can have a huge competitive advantage if your environment responds well to change. A key attribute of being agile is adapting to change.

Thursday, May 7, 2009

JavaScript: The Good Parts


What's the most popular functional language? JavaScript is. And if you are interested in learning the finer points of the language I recommend Douglas Crockford's latest book titled JavaScript: The Good Parts. It is a very quick read at only 145 pages! The most valuable lesson I learned from the book was the correct way to create JavaScript objects with the Module Pattern. The following examples illustrate the Module pattern. This creational pattern leverages closure to achieve encapsulation, information hiding, and global safety. No other JavaScript creational pattern provides these capabilities. This should be your preferred creational pattern in JavaScript.

Module Pattern Examples:

/**
* A search module that provides the ability to search by name.
*/

var search = function (criteria) {
/* private variables */
var name = criteria.name;

/* private methods */
var renderResponse = function() {
alert('rendering response for: ' + name);
};

/* return our public API methods */
return {
execute: function() {
alert('searching for: ' + name); // Perform an AJAX search
renderResponse(); // Perform renderResponse as part of the AJAX callback.
}
};
};


Instantiate a new search object:
search({'name':'Johnny'}).execute();

Run search example


Alternatively, if you prefer to return your public API methods via assignment you may find this example to be simpler:

var search = function (criteria) {
/* private variables */
var that = {};
var name = criteria.name;

/* private methods */
var renderResponse = function() {
alert('rendering response for: ' + name);
};

/* Assign public API methods to that. */
that.execute = function () {
alert('searching for: ' + name); // Perform an AJAX search
renderResponse(); // Perform renderResponse as part of the AJAX callback.
}

return that; // return by assignment example.
};


Module Pattern Advantages

  • Improved encapsulation. For example, if the renderResponse functionality is only pertinent to search, we can encapsulate that behavior within the search object.
  • Better information hiding. No consumers of the search module will be able to call renderResponse directly because it is private.
  • The objects are global-safe. You will not see any references to the this keyword anywhere. This will eliminate any possibility of altering global variables.
  • Requires less effort than other creational patterns (pseudoclassical pattern, Object.create pattern).


JavaScript Resources:

  • JavaScript: The Good Parts presentation from the Google Code Blog.
  • In particular, I found the following sections within JavaScript: The Good Parts to be most valuable for me. These mere ten pages of content were worth the cost of the book!:
    • Chapter 4 (Functions):
      • Closure
      • Module
    • Chapter 5 (Inheritance):
      • Functional
  • JSLint: an excellent tool for code quality analysis.
  • Doug Crockford has at least eight JavaScript presentations available at YUI theatre