Viewing a web page on a web browser has revolutionized the way information is shared, and is one of the most successful examples of the benefits of sustained investment and the commitment to research. Unfortunately, the power of the web is also its greatest downfall. The liberty of publishing your content, with hardly any prerequisites, makes people vulnerable to the designs of certain extremely gifted individuals trying to phish confidential information out of your interactions with the system.

There is a case for users to be more careful while sharing sensitive information on the web. But, the responsibility of protecting its users lies solely with the entity (individual or organization) that publishes the application on the web. With organizational reputations on the line, companies have invested millions into building applications that are safe for users and themselves. The stakes are high!

As a web application developer it is extremely important to make sure that your application is not susceptible to any known or unknown threats posed by systems or humans. In this series of articles, we will analyze some of the common vulnerabilities infecting the world of web applications and application code. We will try to enforce the fact that web application security is much more than just using SSL. SSL can only protect the confidentiality and integrity of data moving back and forth between the client and the server. It does not protect against attacks that are targeted directly at either server or client – and that is where we will focus our attention.

We will kick off our series with a basic but crucial problem – Injection.

Injection

In simple terms, an injection flaw is something that allows an attacker to insert and execute malicious or unintended code within your application. Depending on the system different types of injections may be performed. The two common flaws are at SQL or OS (operating system) level.

Here is an example. Assume we have a customer table with an ID column for storing the details of the customer. The HTTP request for this page looks something like this:

http://<yourcompany>/<yourapp>/getDetails?customer=1111

In the workflow, our code for fetching the details of the customer looks something like this:

String customerId = request.getParameter(“customer”);

String query = “select name, other_details_from_customer_table from customer where ID = ‘“ + customerId + “’”;

This is followed by the code to execute the query, fetch and return the data back to the browser. Once the attacker has access to the request URL of the page, it will be pretty easy for him to modify the parameters and resend the request back to the server. Assume the request is modified to look something like this:

http://<yourcompany>/<yourapp>/getDetails?customer=’ or ‘1’=’ 1

This changes the meaning of the entire workflow and returns the data for all of our customers!

In the worst cases of SQL injection, the attacker can execute a stored procedure that can do a lot more damage than the query stated above. At the OS level, it may even turn out to be the execution of a system command on the server.

Since SQL injection is performed at the database level, attackers may tamper with critical data and in some cases, may even destroy it. If the developer is not careful in the application design, the attacker may even end up executing administrator commands on the database.

Let’s look at an example of OS injection. Assume this is the (Java) code for our application:

//required imports…

public class HelloWorld{

          public string foo(String accountNumber){

                                  try {                                                              

                                                          Runtime rt = Runtime.getRuntime();

                                                          rt.exec(“/u001/some_dir/runscan.sh ” + accountNumber);

                                  }catch(Exception e){

                                                          //all error handling here

                                  }

          }

}

The snippet of code above receives data from a feeder which does not validate the input accountNumber. The method foo accepts the inputs and executes a shell script on the command line with the input as an argument. So far, so good. Of course the developer didn’t anticipate that the input can be fed in with a lot more. Let us assume the method is invoked with the argument “acct1 & ps –aef”. The script (runscan.sh) will get executed with acct1. But because of the & in the input, a second command is appended. Thus, the system ends up executing the process status as well. A similar effect may also be achieved by using an input with a semi-colon. For example: “acct1 ; netstat –anp”.

Now, the good news. All this can be avoided without investing much time and effort. Here are some best practices for protecting against code injection attacks:

Any injection flaw is an indication of bad/incorrect data validation. This data could have arrived through a trusted or an untrusted source. Maybe your application was only meant for real world users, but nothing stops someone from writing a script (or creating a requestor client outside your application) that generates unanticipated scenarios. So, it is extremely important to not restrict yourself by the expected behaviour, usage or even the targeted audience. The workflow illustrated in the application UI is not the only usecase your application will be exposed to.

It is highly recommended that untrusted or unvalidated data not be allowed to percolate down to the DB access layer or to the system layer through your application. Many developers make an incorrect assumption that validating text fields is the only thing needed. The validation list, if one has to create it, is much more exhaustive. Cookies, header data, and post data fields are some of the most common vulnerable entities that hardly ever get the developer’s attention.

On the database level, using bind variables helps us in queries. Another recommended approach is the use of stored procedures. This forces the developer to define the SQL code first and then pass in the parameters. This reduces the possibility of generating queries on the fly like the one in the example above.

Another very good defence mechanism is escaping all user-specified inputs. Some of the Oracle database techniques used for this are discussed in detail on this orafaq page.

It is expected that the database setting will use SET DEFINE OFF or SET SCAN OFF. Creating a specific database user, which does not own any DB object, for the application is a good defence mechanism. This guards the allocation of only required grants to this user.

Last but not the least; a proper code review is the final step towards avoiding injection attacks against your application. A fresh set of eyes can catch vulnerable scenarios or lines of code, which you may think are safe or may have overlooked.

We will close at this point. I will be back with the next episode of this series. Until then, take another look at your code. Is your application secure? Will you bet your paycheck on it? Looking forward to hearing about your experiences of injection attacks and your defences against them.

First smartphones, then tablets…now ultrabooks. The mobile computing space has never been as dynamic and exciting as it is now. Over the course of recent years, mobile computing has improved in such a way that it has almost become a lifestyle.

Ultrabooks are nothing new, and by no means an innovation in mobile computing. They have always been around. Thanks to Apple‘s MacBook Air, the trend has gained considerable momentum. PC manufacturers have always wanted to give slim and high performance devices to the consumer, but Apple laid the foundation.

So what are these ultrabooks?

Ultrabooks can be defined in a few simple words: portable, slim stylish, and fast, with responsive computing interfaces. Like the MacBook Air, the ultrabooks are also powered by Intel low core voltage processors for efficient power consumption and long battery life. However, the two factors that distinguish the MacBook Air from ultrabooks are:

1. Displays. Ultrabooks have a resolution of 1366 x 768 whereas the MacBook Air 13 has a resolution of 1440 x 900.
2. The Ultrabook Intel Core Processors are embedded with security and anti-theft protection technology. Mid-2012, Intel has plans to introduce the Ivy Bridge processors for powering ultrabooks. Not only will the Ivy Bridge processors ramp up performance, responsiveness, and visual display of the ultrabook, but it will upgrade the mobile computing security component. Intel plans to embed McAfee in its core processors for increased malware protection.

Different ultrabook vendors have their own unique selling propositions to market their products. For example, Lenovo’s IdeaPad Yoga can be twisted to behave like a tablet; Dell’s XPS13 is 128GB solid-state drive and has a backlit keyboard; and Acer claims to have built the world’s thinnest ultrabook. In spite of different flavors of ultrabooks available to suit one’s needs, some of the factors that may hinder ultrabook adoption are:

1. High prices. Ultrabooks are priced between 800 dollars and 1300 dollars. If the ultrabook manufacturers can keep a benchmark of 600-700 dollars, it will influence the number of consumers adopting ultrabooks.
2. Support for Windows 8 in workplaces: The 2012 ultrabooks are powered by the Microsoft Windows 8 operating system. Has your IT started or is considering supporting Windows 8?
3. If you like a heavy dose of CDs, DVDs and flash drives, ultrabooks aren’t for you. Ultrabooks, by definition, do not have any built-in hard drives; are powered with solid state drives (SSDs) for better speed and responsiveness; and have low power consumption.
4. The ultrabooks have no outlet or port for LAN support but the mini display port allows you to connect to any type of PC display.

Many industry experts have deemed ultrabooks tablet contenders. But I believe the ultrabooks will eat away at desktops and notebooks. Reason being, tablets and ultrabooks serve different purpose for different user groups. For example, tablets are great reading and entertainment devices for travelers, while the ultrabooks are an ideal pick for students or professors who are always on the move and are looking for high performance boxes. However, I believe, ‘device price’ and technology innovation will play a pivotal role in defining the future of each of these devices.

As the ultrabook revolution picks up the pace, I am already watching the market for new additions to pick one for myself. Are you too ready to dump your netbook or desktop for an ultrabook? Or maybe you own one–if so, please share with us your experiences and any ultrabook vendor recommendations.

Software-as-a-Service (SaaS) eliminates the need to install applications on the customer hardware. SaaS applications are typically accessed from a web browser and a single instance of the application often serves all the customers. Since the same application instance needs to fulfill different needs for different customers and there may be no option of creating a custom build for each customer, customizability of SaaS applications becomes an important aspect for delivering personalized software to the users. Customizability enables easy integration of the SaaS application with the customers existing systems and also empowers partners and resellers to easily configure the solution according to their and their customer’s requirements.

In one of our last posts, we discussed some of the key architecture tenets of a SaaS application – multi-tenancy, customizability, scalability, and security. This post focuses on different customization techniques that we have used in MaaS360 to make it flexible and configurable to address our customers’ and partners’ needs.

1. Look and Feel of a UI: Look and feel is one of the most important types of customizations for a SaaS product. Why?

• Firstly, it provides an option to the customer or a partner to brand the software
• Secondly, by changing the font, colors, and images used in the system, one can make it look similar to the existing systems that the user is familiar with

So, how do you ensure that the look and feel of your application is customizable?

By using CSS (Cascading Style Sheets) for styling the web pages rather than hard-coding the styles within the HTML or JSP. 

Create a set of CSS files that define the default look and feel of your application. For customization, these CSS files can be overridden at a reseller or customer level to personalize elements like colors, fonts, backgrounds etc. The application should pick up the appropriate CSS file based on the user. Images displayed on your web pages can also be customized by storing different images in the file system or the database and picking the relevant image based on the user context.

Apart from the web pages, emails sent by the system to the user can also be customized for content, sender, subject, logos, links and signatures. We highly recommend creating email templates for emails that need to be configured per customer requirements.

So how does this work?

Most of the modern programming languages provide a library to format the date/time/number etc. based on a user’s locale. Make sure you are not hard-coding the display formats but format it based on the logged in user’s context and locale using the in-built functions.

Content localization can be achieved by using language resource bundles in your code. All the language specific content should be isolated from the web pages, so rather than hard-coding English strings in the web pages you should use constants that are replaced by the relevant text at runtime based on the user’s locale and language. If your application uses a database to display the content, the data model must be designed to store the content for each supported locale.

3. Role-based Access: It is critical for a SaaS application to provide different levels of access for different users. For example, in the MaaS360 portal, a Master Administrator can create, publish and assign policies to devices whereas a Help Desk Engineer can only assign policies. Similarly, a customer must be able to customize a user’s role by adding/removing access to certain workflows. It is also important that all portal actions are audited with the user and time information.

MaaS360 achieves this by adding support for role-based access in the application. A set of roles are defined for the application with each role having a set of permissions for different modules of the application. All the application modules check for the required permission before providing access to a workflow or functionality. A user can be assigned one or more roles. When a user logs in, he gets access to the workflows based on the roles assigned to him.

Customizability of a SaaS application can be a big pain if the above points are not well discussed and understood during the design and planning phase. By following these you can ensure that your application is ready for adoption by partners, resellers and customers.

Is your enterprise facing any specific issue while adopting customizability for your SaaS applications? Are there any points you would like to add? Looking forward to learning based on what you share from your experiences.

Now that we’ve (somehow) bounced back from the period of drowsiness synonymous with the Thanksgiving holiday, I invite you to jump right back into the action with me. Continuing from where we left off, I’m going to summarize how the kindle fire chalks up to the iPad 2 in terms of tech specs.

Chris Corbet opened Round 2 with a very interesting tablet fact, shared with us by a member of the 451 Group: The tablet took only 20 months to ship 100 million devices, where the PC took 20 years and the smartphone 6 years. The dramatic difference in rate of adoption makes our comparison between the kindle fire and iPad 2 all the more worth reading into…

Jon Dale took the first jab in this round breaking down the iPad 2. This tablet weighs in just over 1 pound and has different storage options depending on what you prefer. If you have to keep your content local to you, the iPad 2 can store up to 64 GB. On the other hand, if you’d like to keep your files off the hard drive you can go with the more inexpensive option with less capacity. No matter which you choose, you’ll have a 1 gigahertz processor and great battery life that lasts up to 10 hours with Wi-Fi enabled and 9 hours using 3G. Apple’s App Store makes over 100,000 apps available for you; no matter what you need to use the iPad for, rest assured there is an app out there that can help you get it done.

Donna Lima struck back with a description of the kindle fire, smaller in size and no doubt the underdog in this match-up. When compared with a standard tablet the fire is a little smaller, about the same size as the BlackBerry Playbook. It has a nice screen size for the readers and movie-junkies out there, but beware it is slightly heavier than the Kindle reader you may be used to. The speakers are situated right at the top of the device so the sound stays clear when watching films. This tablet comes with a modified Android OS, which doesn’t look like or function the same as what you may be used to with other Android operated devices (one of the only features you’ll find similar is the notifications bar).

The iPad 2 certainly got its punches in this round, as the fire relies mostly on your interaction with its touch screen. Bad news for iPad though: the fire’s screen is almost indestructible and only has one button for powering on and off (yet another adjustment Kindle owners will have to make). In terms of storage the fire does not compete with the iPad 2 by any means, but does make it easy to store your files on the cloud free of charge (easy to access the same files from phone or PC). Battery life is the only question mark that remains. Since this device is capable of doing so many things, it will take a few weeks to see which processes drain the battery the most. On a good day, the battery will last up to 8 hours. There’s no camera and not nearly as many apps, but the huge difference in price delivers a noteworthy blow to the iPad 2 at the end of this round.

So…let us know which tablet you’d pick based on this Round 2 comparison. If you haven’t made up your mind yet, read a recap of Round 3 or Round 4 and I’m sure you’ll be able to share something! If you don’t feel like reading you can watch a recording of the event here.

With the increasing popularity and penetration of the cloud, SaaS (Software as a Service) is rapidly becoming the preferred software delivery model for organizations across the world – software buyers as well as vendors. With SaaS, software is hosted by the vendor (service provider) in the cloud and accessed by the users over the Internet using a thin client e.g. a web-browser. There are many business benefits of adopting SaaS. For the customer, it means reduced cost of ownership, fast deployment, no maintenance headaches, and a smaller learning curve leading to a higher adoption rate in the user community. For the vendor, it means reduced cost of customer acquisitions, faster sales cycles, more upsell opportunities and an easier rollout of new features.

From an engineering perspective also, SaaS is a great way to build and deliver software. It is a perfect fit for software delivery teams that have adopted an agile development model. As the software is centrally hosted, you can:

1. Deliver new features to your customers faster
2. Receive user feedback and implement changes in real time
3. Fix production issues quickly

Also, you need not worry about any environment dependencies, different software versions, their
upgrades, etc.

So, excited about building a SaaS product? OK, let’s see what you must know for building SaaS software. The following are the key architecture/design tenets of a SaaS product:

Multi-tenancy:

Multi-tenancy is the ability to serve different customers from a shared hardware or software instance. It gives you economics of scale by catering to a growing customer base without any significant increase in your resources. From a software design perspective, multi-tenancy influences all aspects of software including database model, application logic, user interface, etc.

At the database level, multi-tenancy can be achieved either by storing data for each customer in a separate schema or by partitioning the customer data by adding a customer qualifier field to all entities (i.e., Customer ID should be part of all tables as a primary key field). The second approach is straightforward and can be implemented very easily. It may suffice for systems that do not have a large volume of data. However, for systems that deal with large data volume it is best to store each customer’s data in a schema of its own. In both cases, you must spend some time building data access frameworks to hide the underlying data partitioning scheme from developers. This not only makes your developers’ lives easier but also helps you to migrate from one scheme to another when the need arises.

Scalability:

Well, scalability is important for any software system worth its salt. However, it becomes extremely important for a SaaS system because any performance impact directly affects all your customers. If one of your customers starts uploading large volumes of data, it should not start impacting other customers. Database multi-tenancy discussed above takes care of scalability from the database operations side. To ensure that your application servers are scalable, you must ensure that your applications are cluster enabled and you can add cluster nodes as your data volumes grow. It is best to make all your application services stateless so that you do not need to worry about session persistence/replication, etc.

Another design principle to follow, while designing scalable systems, is modularizing your services. This not only makes your system more fault-tolerant but also allows you to scale the different components based on the number of requests each component receives. Another important tool you should exploit is cache. In a SaaS system there is a lot of data that is common across customers (e.g. country codes). Such meta data can be cached and be made accessible across the system. This will avoid unnecessary database operations and boost system performance.

Security:

As the data for all customers is stored in the same data-store, it is very important to ensure that one customer’s data is not accessible by another. This means deploying several levels of defenses. For instance:

• At the database level, you must encrypt all confidential data – preferably by using a unique key for each customer.
• At the network level, you must ensure that all the communication happens on a secured channel (e.g., HTTPS should be used for all requests from the browser to application server).
• At the application level, you must ensure that all the workflows authorize the user before granting access to any data. Authorization must be performed on the server side for each request rather than depending on the client for it. Also, ensure that your website conforms to security best practices.

Customizability:

If you have been in the enterprise application space for more than a few months, you would know that no two customers are the same. Each customer has different requirements for data modeling, UI workflows, integration with legacy systems, etc. As a SaaS system developer, you should realize this early and ensure that the system provides customization capability for all important elements, e.g., the UI look and feel, data interchange formats, definition of entities and business logic, as well. When designing your data model, think how your users can extend it. When designing your business logic, think how the user can alter it. It is a good practice to model business logic as a template that can be changed by your users. When designing your UI look and feel, think of different themes, logos, icons, etc. Customization becomes very important if your business model involves partners to resell your solution; they’ll probably want to rebrand your solution and customize the workflows.

As a pioneer in the SaaS space, MaaS360 has used these and some other design principles and has ensured that our applications are secure, scalable and customizable. We’ll discuss these concepts in detail in the coming posts. Meanwhile, please share about your experiences of building/using SaaS solutions in the comments section.