Monthly Archives: December 2010

OWASP Top 10 Web Application Security Risk

The OWASP Top 10 Web Application Security Risks for 2010 are:

  • A1: Injection
  • A2: Cross-Site Scripting (XSS)
  • A3: Broken Authentication and Session Management
  • A4: Insecure Direct Object References
  • A5: Cross-Site Request Forgery (CSRF)
  • A6: Security Misconfiguration
  • A7: Insecure Cryptographic Storage
  • A8: Failure to Restrict URL Access
  • A9: Insufficient Transport Layer Protection
  • A10: Unvalidated Redirects and Forwards

In the course of your work, how often have you entered them? Is your web application designed with security in mind from the beginning? Or security is an after thought, after failing penetration tests from external security consultants? For more details on the top 10 web application risk, read here.

Advertisements

Optimistic Currency Control

One of the typical challenges that a web application would encounter is concurrency. A data could be modified by multiple users all at the same time. The challenge is to persist the correct data.

For example, I took two mobile lines with my telco and I decided to inform the HR executive, Amy, about my new number. Somehow I decided to use the first number for business usage.

Amy logs into the HR application online and starts to enter my new number. Before she could save the entry, she was hijacked by her boss for a short discussion. At this time, for no particular reason, I felt that it would be better to use the second mobile number instead and decided to tell Amy. As she wasn’t around, I told her colleague, Betty. Betty did the change for me immediately. Satisfied, I left.

When Amy return, she clicked the save button and my mobile number was overwritten to the one that I do not wish to use instead.

Now, this problem could be avoided with several methods. We could have prevented Betty from saving the change. That is, we lock the record and prevent anyone else from editing it once someone gains access to it for editing. This is viable, but it is not productive. However, this approach is perfectly fine if we’re in a single user environment. That is, only Amy has access to perform the edit. If this is not true, then the approach is flawed operationally. What if Amy forgot to complete the update and left for vacation? My number would never be updated.

The other solution would be to use optimistic locking. Instead of preventing others from editing the record, we allow multiple edits to happen concurrently. However, during saving, we check if the save would be correct. Using the same example again:

  1. Amy edits my record, the system detects that my record was last updated at X time.
  2. Betty edits my record, the system detects that the last modified timestamp was still X as Amy hadn’t save. Betty is allowed to update my record. The system updates the last modified timestamp to Y.
  3. Amy attempts to save her changes. During the save operation, the system detects that the last modified timestamp is no longer X, and Amy is disallowed from saving.

Some folks use a version number for this approach, however, this would mean that our database design has to cater to this. I prefer to use timestamp as the column has practical uses and it is still acceptable for database design. Even if I were not to use locking anymore, the column is still valid and not unnecessary.


Java tips: null Vs empty

To understand when to use null and when to use empty, we first need to know what are their differences. Well, null, simply means null. The object is non-existent. You will hit a nasty NPE should you try to use a null object. Typically, empty refers to data structures such as List or Collection. These data structure can contain zero or many objects. So when there’re no objects contained, the data structure is said to be empty.

The debate comes in here whereby one group of developers would argue that if the data structure does not contain any object, we could make it null, no need to instantiate an empty ArrayList or Vector. However, on careful thoughts, using null to represent empty data structures is flawed for a few good reasons.

A data structure is empty but not null. The data structure exists and hence it is capable of being used when needed. By setting it to be null, it is implying that no such data structure exists.

There’re many instances whereby you would typically iterate through a data structure to access its contents. If the data structure is set to null, you would have to do an additional null check every time you access it. This is unnecessary if you have an empty ArrayList or Vector. The for-loop would not even execute. So in realty, you have a performance gain and your code is actually more readable and compact (no need for unnecessary checks).

I would even go far enough to say that this is one of the best practices as seen in Java API. This is particularly useful when you’re providing your own API. The client code need not be defensive and could focus on accessing your returned data structure.


Synchronized Vs Unsynchronized

In a multi-threaded environment, there’s always a risk of data being altered concurrently by multiple threads. There’re certainly numerous ways of preventing this from happening. The Java language has its own mechanisms to prevent this issue. To prevent concurrent access, we could use data structures that are synchronized. By being synchronized, it just meant that access to the data structure itself is done in a synchronized manner.

Some examples of synchronized data structures are: Vector, Hashtable & StringBuffer. There’s two sides to the story. With synchronized access, you get penalties on scalability and speed. Granted, there’re arguments that with the newer JVM and increase in CPU speed and memory, the performance (speed) issue isn’t that significant. But there’s always the scalability issue to consider.

The counter-parts to these synchronized data structures are: ArrayList, HashMap & StringBuilder. It’s highly recommended to use them in a single thread environment.

But things aren’t so simple between Hashtable & HashMap. Their differences do not stop at being synchronized and unsynchronized. Hashtable does not allow for null keys nor values. HashMap on other hand, allows for both.

Other than synchronizing at data structure level, we could do so on the method or block-of-codes level. These are more recommended. In a situation whereby your data structure can be accessed in a single-thread and multi-thread environment, you could have two methods (synchronized and unsynchronized) accessing the same data structure.

For reusability reason, synchronized methods are preferred over synchronized statements.