Introduction

In a fast evolving online market place, every business relies heavily on the latest technology to ensure data, applications and customers’ online transactions are fundamentally secure. Simultaneously, online businesses are constantly grappling with issues related to security as e-businesses process a lot of sensitive information
¾ their own and their customers ¾ that is stored and processed in large numbers. Due to the phenomenal growth in e-business, there are a number of reasons for online businesses to adopt the latest cutting-edge Web 2.0 technologies:

Business Driven

• Attract more customers.
• Higher customer conversions.
• Retain more customers.

Security benefits:

• Client side robustness.
• Seamless third party integration without compromising on security.
• Relatively secure combinations of several technologies.

Scalability and Robustness

• Cross-domain possibilities.
• Ajax-based applications are more flexible than page-centric interactions.
• Ajax and Flex applications are highly scalable without major architectural changes.
• Fewer server interactions.

Security Features of Web 2.0 Applications

Web 2.0 applications like Google Calendar and MySpace.com cater to high-volume user interactions by utilizing technologies like Flex, AJAX etc.–. The sections below discuss the inherent security aspects of different categories of Web 2.0 technologies

Security of Flex Applications

Flex applications protect both the client and the server.

Client Side

Applications developed using Flex execute within Flash Player and thus run inside a security sandbox that prevents malicious attempts on their application code. The sandbox ensures that Flex is a standalone application, running only inside a browser, and prevents unauthorized access to the operating system environment as well as other local instances of Flash Player. Flex has an extensive list of features that ensure Flash content is secure, including the following:

• Encryption capabilities of SSL in the browser to encrypt all communications between a Flash application and server
• Sandbox security system that limits transfer of information that might pose a risk to security or privacy
• Prevents applications from reading data from and writing data to the local drive, except for shared objects that were created by that domain
• Does not allow web content to read data from a server that is not from the same domain, unless that server explicitly allows access
• Enables the user to disable the storage of information for any domain
• Does not allow data to be sent from a camera or microphone unless the user gives permission

Server Side

Flex Data Services, being a J2EE application, only uses J2EE authentication and authorization techniques to prevent unauthorized users from accessing applications. Since Flex Data Services leverages J2EE security, it includes several built-in security mechanisms that let you control access to web services, HTTP services, and Java classes such as EJBs, which are different mechanisms to implement security measures in layers. These security mechanisms also help mitigate common attacks against infrastructure components, such as buffer overflows, heap corruption and cross-site scripting.

Security of AJAX Applications

With Web 2.0, a lot of the logic is shifting to client-side. This may expose the entire application to some serious threats. The urge for data integration from multiple parties and suspected sources can increase the overall risk factor as well. Conversely, Ajax can be used to build applications with seamless data integration. However, one insecure call or information stream can backfire and open up an exploitable security hole.

These new technology vectors are promising and exciting to many, but they’re even more enticing those who write viruses and worms. All the more reason for developers to pay detailed attention to security during implementation. Oddly enough, until recently, use of client-side scripts for input validation was discouraged by security professionals because they can be circumvented easily. To deal with these security issues, Ajax validations must be placed on incoming streams before they hit the domain. Close attention must be paid to XML parsing and cross-domain security issues and the simple thumb rule of not implementing cross-domain information without proper validation followed.

If Web 2.0 is not implemented properly, it may open up gaps that can be leveraged by attackers, worms and viruses with identity compromise the final outcome.

Mashups

Major security issues used to crop-up in older legacy applications during the integration of different web applications where achieving seamless information exchange problematic. Mashups have changed all that.

Mashups take information available on separate applications and “mash” it together to give a combined, related, useful output including seamlessly merged third-party applications such as Salesforce.com (CRM) and Trumba (a tool for publishing event schedules). Previously, Mashups were available to large companies with sizeable budgets for software development; however, growing awareness, availability of skilled resources and more companies embracing the technique have put this within reach of most companies.

Web 2.0 applications with online data store

Social networking sites like MySpace.com and utility applications like Google Calendar store users’ critical data. These applications have lot of security checks already in place, but whenever data is stored online, there’s risk from hackers attacking these sites and manipulating data. This is illustrated by the Samy virus that hit 20 million users of MySpace.com ¾ though no harm was done to the user’s operating system, online data was compromised. Applications like these are prone to attacks associated with cross-site scripting and cross-site request forgeries.

Scenarios with Potential Security loopholes

In order to illustrate security concerns with Web 2.0 solutions, we’ll look at some common scenarios that may be encountered by an online retail company.

Scenario 1

A single screen checkout is implemented and while the user enters billing information, another asynchronous call is made to the server to get previously saved shipping addresses. If the application does not handle this correctly, cross-site scripting issues can be introduced.

This is similar to a classic web application where a form is submitted, then validated on the server and the next set of data is populated on a new page. With Web 2.0, the page view remains while sections of the page submit data and map the response to the next UI widget ¾ in this case the shipping screen. If data is not handled properly, this will introduce security issues.

To prevent such security issues, proper server side checks that stop malicious code from being executed should be implemented to validate requests coming from the Web 2.0 client. The server should also implement proper access control mechanism, either through a software-based solution or by configuring the servers correctly.

Scenario 2

Web 2.0 applications typically involve a lot of small Ajax-like applications embedded in a page that make asynchronous calls to server to update sections dynamically. If the QA team is not made aware of all testing scenarios on that page, they can easily miss testing some of them, opening the door for security issues.

Proper synchronization with the development team would make the QA team aware of all widgets that are being implemented and reveal the proper testing mechanism. (A fair amount of testing tools now support testing Flash and AJAX based applications.) They should check for requests that originate not only on the browser URL, but also asynchronously from the page itself. One way of doing this would be to use tools like “TcpTrace” that tracks all requests originating from the client. Developers implementing Web 2.0 solutions should also be aware of such tools so they can do unit-testing of all requests to secure the server-side.

Scenario 3

An accordion-like UI interface is implemented for a single-screen checkout. While most of the data can be accessed over an http connection, personal information like login details and credit card information should be brought to the server over a secure connection. While filling out payment details, the page might be served over http  and security issues may exist. UI design for Web 2.0 might require some data to be sent over http and some over secure channels. If not implemented correctly, the security issues caused by getting data over https might be missed.

When designing Web 2.0 applications, security of personal data should be kept in mind. All Web 2.0 technologies support transmitting data over https connection, so proper safeguards must be in place to ensure developers and QA don’t overlook testing to make sure data is passed on through https rather than http.

Scenario 4

Classic web applications usually have strong encryption algorithms implemented using current programming languages like Java, .NET etc. Since the data is posted to the server and communication happens over https, encryption and decryption can happen on the server side.

With Web 2.0, a lot of server side logic shifts to the client and there will be cases where encryption needs to be done on client side. For example, credit card information entered by the user needs to be encrypted on client side using either a security key or an algorithm. But even as some Web 2.0 applications take measures to prevent users from understanding the algorithm implemented or key used, these still can be decoded using tools like flash decompiler or  tcpTrace, leaving client logic is open to scrutiny and introducing security issues.

One way of securing flash applications is to encrypt flash movies before uploading them to the Internet. This will prevent flash decompiler from checking the codes and decoding security keys or the encryption algorithms. If there are standard encryption algorithms available on client side, the security key can be protected by relaying it over an https connection rather than storing it locally in the client. A fail-safe mechanism would be to do these transactions over https connection so that the secure channel between the browser and server prevents hackers from interpreting the data communication.

Scenario 5

Sometimes Web 2.0 developers go a bit too far when designing a widget for an application; for example, “autosuggest,” where a user types  letters in a text box and the server comes back with suggestions for possible matches. As each letter is typed, a new call is made to the server. If the server was designed to handle a particular load, say of 1000 concurrent requests, and the site is operating at its peak load, adding a widget like this can overload server capacity, which could be mistaken for a kind of “denial-of-service” attack on the server.

When adding widgets, companies should take into account not just the “cool” factor, but also the server load capacity. It is nice to ask server for bits of data and not reload the page every time there’s a user interaction, but sending too many requests to the server is not a great design. One way to prevent this could be to cache some data on client side when the application first loads and only go to the server if the cache is corrupted or the requested data is not available in the cache. Server “push” technology can also be utilized where the server pushes data to the client periodically so that each user interaction does not generate a server request and instead uses the data already available in cache.

Conclusion

Web applications of earlier years were simplistic ¾ mostly form-based applications. Today, web applications are more complex and therefore more vulnerable to malicious attacks. If security is not addressed while building applications, common client side attacks are possible including: cross-site scripting, denial-of-service, SQL injection etc and other server side susceptibilities. However, Web 2.0 technologies can provide sufficient checks to secure against these, provided the company implementing the technology knows of them and follows security standards. Therefore, companies seeking to incorporate Web 2.0 technologies into their web sites should be sure that development is being  implemented by a firm whose core competencies include the skills, past experience and specific focus on these technologies as they would know the best possible ways to forecast and mitigate risks that are associated with building such complex web solutions.