In this article, I'll show you why online collaboration is getting more popular with Web 2.0 tools and how it comes with vulnerabilities that can be exploited by hackers. I'll cover how to mitigate or eliminate vulnerabilities by identifying assets, assessing vulnerabilities, and implementing safeguards where possible. I'll highlight SQL, XML, and Ajax injection vulnerabilities as examples and show you how to fix them so you can guarantee uptime availability with a Service-Level Agreement (SLA).
Web-based collaboration is gaining momentum at many organizations with Web 2.0 tools such as online meetings, social networks, blogs, wikis, bookmarks, forums, podcasts, and many other tools that reinvent how people interact on the Web. You can use RSS feeds to browse through the most recent documents for group discussions between managers, systems engineers, systems architects, and potential customers. With these tools, customer service improves, and you can accomplish more in less time.
Simple vulnerability assessment
An online collaboration development project can be simple if you already have components that can be reused as inputs into a composite application. Many of these collaboration tools are based on open source software and are widely distributed.
However, the hosting and security of these environments can vary. Open source means that many eyes can look at the code for vulnerabilities, but you have to ask: Is the component you are using mature enough or popular enough to receive that sort of scrutiny? Working through the Internet through different components, some information may even be transmitted through insecure channels. All of these are points which could be vulnerable to attacks by hackers and other intruders. To mitigate these vulnerabilities, you need to conduct a vulnerability assessment. Always establish a security policy before you perform a vulnerability assessment.
Let's look at the elements of a simple assessment:
- Identify critical system assets
- Assess vulnerabilities
- Determine asset replacement values
- Implement safeguards
The first step says you need to identify critical system assets—tangible and intangible—that are most likely vulnerable to malicious attacks.
A tangible asset is an object you can see, feel, or touch. It could be a human resource, such as your WebSphere Web developer system administrator. It can be a piece of software, such as the tools you use to develop the online collaboration project. It can also be hardware such as servers, network infrastructure, and so on.
An intangible asset is an object you cannot see, feel, or touch but that still has value. For example, the information that you exchange through your collaboration is an intangible asset.
After you get all the assets for assessment identified, the next step is to identify and assess the vulnerabilities of each asset that a hacker or attacker could maliciously exploit. Next you determine the replacement costs of each tangible asset for a specified period of time (usually a year). It may take more than one vulnerability to be exploited before a threat can happen. For each threat, you should assign ratings of risk impacts for each asset.
Finally, you determine the possible remedies and safeguards, such as off-site backup of online collaboration. Your goal is to mitigate the risks of exploiting vulnerabilities to an acceptable level. Make sure benefits exceed or are equal to the costs of a safeguard. If the costs are too high, you may end up with a residual risk for the online collaboration project.
Complex vulnerability assessment
If the online collaboration development project is complex (for example, development from the ground up), you can expand the steps:
First identify and prioritize assets—tangible and intangible—associated with the development project. After putting the assets together, you then identify and assess vulnerabilities on a regular schedule. If the vulnerabilities of each asset change before the due time for another assessment, repeat the first two steps.
Next, measure the level of business risk associated with your assets according to your security policies. After you assess vulnerabilities, prioritize them according to business risk. Always verify that the implemented safeguards accomplish what was intended through follow-up audits. The safeguard that was cost-effectively implemented in the original assessment may need to be replaced with a better one for less money. Newer technologies come along and many things can change since the last assessment was done.
The range of online collaboration vulnerabilities depends on project complexity, interrelationships with similar projects, and whether the security policies are in place. For this article, I'll highlight those exploitable vulnerabilities that would impact the uptime availability in the SLA. They are SQL, XML, and Ajax injection vulnerabilities. We'll look at how you can find the lines of code containing these vulnerabilities and eliminate them so the uptime availability stays high.
When the problems in the code have been fixed, you still need to consider interruption thresholds. An interruption threshold is the difference between the time a request for the information was initiated and the time a response to the request was sent. If the time gap is large, interruption thresholds could reach the level that could be exploited by a hacker, causing an adverse impact on the uptime availability. Sometimes this is still a coding issue. You may need to adjust how information is sent. You may need to change the format or handle information in smaller chunks. Sometimes such issues are as simple as upgrading hardware or ensuring that you have the latest patches or versions of your software running.
SQL injection is still one of the most common types of an injection flaw. A hacker could use this attack technique to retrieve, corrupt, or delete data. He could shut down online collaboration without warning, leaving the meeting participants out in the cold. He could also obtain confidential information without any of the parties being aware.
Here is how an SQL injection works: First, assume an SQL statement accepts user-supplied data to look up a team member's contact information from a database without input validation rules. The attacker injects his malicious inputs to the SQL statement to change the query's logic. He concatenates strings with SQL syntax and appends his own data.
Shut down scenario
In this scenario a query gets the name and e-email address from a user, as in the following example.
Listing 1. Query string with no input validation rules
dim strQuery as String strQuery = "SELECT NAME, EMAIL from users WHERE userid * + Request.QueryString ("userid")"
The query shown does not contain input validation rules. When the hacker supplies the data, the query does not check if the userid parameter is validated.
For instance, if the hacker enters "42; SHUTDOWN WITH NOWAIT" as his userid, he modifies the query string like this:
Listing 2. Query string with malicious code
SELECT name, email FROM users WHERE userid=42; SHUTDOWN WITH NOWAIT
As you can see, the hacker changes the query's logic by entering the malicious code as his userid. The query does not check if the input is valid.
Source code analysis
To find the problem with any SQL injection, perform source code analysis. This method will help you eliminate the lines of code where the vulnerability exists even in the stored procedures.
To prevent the hacker from exploiting the vulnerability, not only must you re-construct the query example with input validation, you must also ensure the hacker cannot log in. Without input validation rules, it is easy for the hacker to manipulate a query string so he can shut down the online collaboration Web page.
XML injection is a newer type of attack. Both Xpath and Xquery provide the means to query XML documents. They are both vulnerable to attack using the same techniques shown above with SQL injections; the data store just happens to be XML files instead of an actual database.
As with the SQL injection, it is possible for the hacker to manipulate an XML query to delete or corrupt data, or to cause the online collaboration service to shut down with no waiting period.
XML injection is more prevalent with the increased use of Ajax portals and Web services, both of which rely heavily on processing XML data streams. XML injection is becoming an important issue when these Web services are asynchronously connected to Ajax portals where the hacker can provide malicious data inputs.
As in the SQL injections, source code analysis is the only real way to eliminate the vulnerability. You'll again want to re-construct the query example with strong input validation rules and ensure the hacker cannot log in with his malicious userid.
The problem is that in the pursuit of performance, developers tend to store more and more data (often sensitive) on the client side. They may not realize that the hacker can access all data and functionality, including the injection of malicious code into the client-side Ajax scripts, which then interact with the server handling requests.
You might be better off storing the data in a database on the server. If the data must be stored on the client side, then it should be replicated on the server. When the server gets a sign that the client data is corrupted, or compromised, it can send a copy of the data store to the client. This allows normal operations to continue between the client side and the servers.
As these attacks evolve there will be tools to assist with code analysis that will give information to help you find the lines of code where the vulnerabilities exist. You must be careful about storing data on the client side and exposing the functions to a hacker who can get the data. You can also obscure the source of the client-side application with a commercial utility such as HTML Protector or HTMLGuardian, but that may just slow the hacker down rather than stop him. Obfuscated HTML will also not be read by search engines. The best solution is to not include more information on the client side than you need to and to do regular validation of information going both from and to the client.
Finishing the picture with an SLA
Finally, after you've done all that you can with your resources, you enter into the final level of protection, the SLA. To have an accurate SLA you should do adequate testing of your solution. In addition to response time, you should test access, time-outs, and versioning. Testing access will help you find out if an unauthorized user can successfully access a control that only the administrators are authorized to use. Testing time-outs will help you find out what happens when the collaboration times out after a certain period of inactivity. Testing versioning will help to find out if a new build to the collaboration service will break an existing collaboration service's functions.
If you are in the role of a service provider, include in the SLA one or more statements that lines of code containing vulnerabilities of SQL, XML, and Ajax injections have been eliminated from your software tools.
Service of credits will be given if uptime availability is not guaranteed after a specified period of time with the following exceptions:
- Failures such as software monitoring/measurement system failure, and telecommunication software
- Network issues not within direct control of the service provider
- Scheduled maintenance, such as software upgrades and periodic backups
- Denial of service due to client negligence and willful misconduct, network floods, and other acts of God
You will not as likely need to give service of credits if you conduct thorough testing of the collaboration software and cleanse it of the lines of code containing vulnerabilities, replacing them with ones containing strong input validation rules. This should be true whether the vulnerabilities are in the stored procedures or in the source code on the client side. Encrypt your source and data where you can. It does not matter what technologies you are using—Java EE, ASP.Net, or Php.
This article helps you plan for reducing online collaboration vulnerabilities by showing you how to find and eliminate weaknesses in your code and infrastructure and advising that you have solid agreements with clients and service providers that help uphold your efforts. Users' demands for continuous uptime availability guaranteed in the SLA present a challenge for developers, business analysts, systems administrators, and other members of a project team. The task of protecting your application is never done. New technologies and techniques will require you to refactor your choices over time, both to find new weaknesses and improved solutions. Dedication to keeping vulnerabilities at the accepted level of business risk can make your team's experiences trouble free.
- Browse Judith's series, Use SLAs in a Web services context, which has details on Service-Level Agreements.
- Want more information on Ajax tools? Read about them in "Survey of Ajax tools and techniques" (Gal Shachor, Yoav Rubin, Shmulik London, Shmuel Kallner, developerWorks, July 2007).
- Read Judith's The Complete Book of Middleware, which focuses on the essential principles and priorities of system design and emphasizes the new requirements brought forward by the rise of e-commerce and distributed integrated systems.
- Stay current with developerWorks technical events and webcasts.
- Check out My developerWorks: Find or create groups, blogs, and activities about Web development or anything else that interests you.