 | Level: Intermediate Judith Myerson (jmyerson@bellatlantic.net), Systems engineer and architect, Freelance writer
28 Aug 2007 Deploying bandwidth-efficient Ajax applications does not guarantee
that the service levels in a Service Level Agreement will stay high. No matter how
well you change code in the Ajax format to make it more bandwidth efficient, there
will be always risks and vulnerabilities you'll need to watch out for and mitigate.
Regular developerWorks author Judith Myerson gives a brief Ajax recap, shows what
Web services vulnerabilities are and why Service Level Agreements (SLA) are important, and suggests some solutions for speeding up Ajax applications.
Introduction
In my recent developerWorks series
Use SLAs in a Web services context,
I talked about securing multiple Web services, firewalling Web services, and mitigating risk for vulnerability, all with an SLA guarantee. I focused on the importance of high availability of service by a producer for the consumers though various performance and standard criteria.
This article starts with a recap on Asynchronous JavaScript + XML (Ajax), gives
some vulnerability issues, discusses SLA impacts, and then shows why
bandwidth-efficient Ajax applications do not guarantee that risks to
vulnerabilities will be mitigated or eliminated. It also covers ways of speeding up your Ajax applications while dodging Web services vulnerabilities.
 | | New security vulnerabilities to your Ajax applications have
emerged as a result of Ajax moving from browser applications to server portals
over the Internet. This article gives practical advice on dodging Web services vulnerabilities while speeding up your Ajax applications. |
|
Ajax recap
Ajax enables responsive and interactive Web services by transforming a user's
browser experience (for example, a business-to-business transaction) into an XML-based Web services portal (such as a business-to-consumer transaction). Ajax accomplishes this by building an extra layer of processing between the Web page and the server over the HTTP protocol. This layer intercepts requests from the user and in the background, communicates with the server quietly and asynchronously to get the desired content of an HTTP protocol. It is not necessary to have server requests and responses coincide with user actions, such as a request for an update to a database record and a response that the update was successful.
Web services vulnerabilities
Let's address some concerns about an extra layer of processing. One concern is that
because it relies on XML as the content type for requests and response payload, Ajax increases the amount of XML traffic being transmitted. When used in massive quantities, Ajax applications can clog up network traffic. A more important concern, in turn, is that the large amount of traffic exposes Ajax applications to Web services vulnerabilities. When these vulnerabilities are exploited, the system or applications will perform poorly.
 |
The developerWorks Ajax resource center
Check out the Ajax Resource Center, your one-stop shop for information on the Ajax programming model, including articles and tutorials, discussion forums, blogs, wikis, events, and news. If it's happening, it's covered here. |
|
Let's take a look at four vulnerability instances:
- Excessive bandwidth
- Corrupted data
- Frequent small HTTP requests
- Memory leaks
Excessive bandwidth
XML messages in text format could more than double the amount of bandwidth of binary
data. The more bandwidth that is needed to transmit XML messages, the less resource there
will be for the system or application to perform other tasks, such as performing complex
algorithms to get the desired result. Excessive bandwidth could result in performance
degradations caused by system overloads.
Corrupted data
Excessive bandwidth could contribute to corrupted data outputs from Ajax applications
because there are insufficient resources to produce clean data. This means that Web services portals, of which the Ajax applications are a part, could expose corrupted data to other parts of the portal, resulting in malformed messages and excessive parsing. This vulnerability, if exploited by a threat, could result in a browser crash.
Frequent small requests
One drawback of Ajax is that it allows you to make many small requests instead of one big post-back. Frequent, small HTTP requests can stress back-end servers, load balancers, and firewalls and result in excessive bandwidth, causing performance to degrade. They can bump up against browser limits or a sluggish network connection, causing network bottlenecks.
Memory leaks
In a typical Web application, Web pages are frequently reloaded, wiping out the memory
for that page and starting with a clean state. With Ajax, you can avoid page reloads
while waiting for the next piece of content to be presented in the Web services portal. With Ajax, you can have a single-page application stay in the browser for days, magnifying any problems with memory or other resource leaks that may occur. Excessive memory leaks -- along with excessive bandwidth and small HTTP requests -- may contribute to corrupted data in the Web portal, increasing the opportunity for the hacker to exploit system vulnerabilities from the Internet.
Risk assessment
For all instances, you need to determine how high or low the risks are that a threat
agent could take advantage of system and server vulnerabilities and the resulting business impact. High risk necessitates that safeguards be in place to speed up Ajax applications. One safeguard instance is to increase service uptime availability with an SLA guarantee.
The Service Level Agreement
No matter how well you can change the codes in an Ajax application to make it more
bandwidth efficient, there will be always risks and vulnerabilities you'll need to watch
out for and mitigate. Deploying bandwidth-efficient applications does not guarantee that the service levels in an SLA will always stay high, at, or above the specified performance threshold point (for example, 99.9 or 99.999%). Applications become more vulnerable as they go from a browser application to a server portal in an Ajax application over the Internet, particularly the XML part used to build Web services to detect performance problems, such as packet losses.
You need to consider three things to improve service uptime availability. First, to
speed up Ajax applications, you should address the means of improving performance other
than bandwidth optimization (such as XML content filtering and XML acceleration
capabilities). Second, to secure Ajax applications, you should consider Web security
standards, such as WS-Security (WSS), Application Vulnerability Description Language
(AVDL), and a host of others. Third, you should consider traffic monitoring of these applications as one of the tools for measuring performance.
Improvement #1. Speeding up applications
Let's take a look at the following options for speeding up Ajax applications:
- Specialized hardware accelerators
- Optimized software
- Code redundancy elimination
- XML acceleration capabilities
- Interoperability issues resolution
Specialized hardware accelerators
Hardware accelerators are used to speed up XML traffic. Without the accelerator, encryption, complex graphics, and speech recognition algorithms can tie up applications and associated resources because it must perform complex calculations to get the desired result. The accelerator is generally not for server-side scripting. The alternative is to combine hardware accelerators with optimized software.
Optimized software
Optimized software is used to modify and compress a system so that an application can
execute more rapidly or operate with a reduced amount of memory storage and other
resources. Optimized software draws less battery power in a portable computer. Reducing
size and time of downloads from servers is a two-step process:
- Use ASP.Net or JavaScript technology to analyze Ajax application payloads.
- Develop optimized software based on the payload analysis.
Code redundancy elimination
One example of eliminating code redundancy is to reduce the number of Ajax callbacks and the payload for each callback. If there is a complex interaction between callbacks, look for redundant codes and simplify them. Another example is to divide Ajax applications into modules and combine those with similar functions to reduce redundancy.
XML acceleration capabilities
Depending on the complexity of the application, high overhead costs of processing parsing large files of text-based XML
offset the benefits of hardware accelerators and optimized software
eliminating code redundancy. Text-based XML Web services applications are large and tend to get bloated and therefore are not bandwidth efficient from a network, processor, and storage performance perspective. When large files are used in massive quantities, these Web services can clog up network traffic, resulting in system overloads.
One of the major hindrances to Web services performance is the network and processing
overhead associated with XML. As a result, there has been a push in the industry toward
standardizing on a binary encoding scheme for XML, such as the XML-binary Optimized
Packaging Specification (XOL) Package. As discussed in Part 7 of my series on working with Web services in enterprise-wide Service-Oriented Architectures (SOAs), I discussed how this package is more effective in the processing of large files in binary than the XML parsers for text-based files.
Interoperability issues resolution
No matter how well Ajax applications are optimized, what hardware accelerators have been used, or how code redundancy has been reduced or eliminated, you need to resolve interoperability issues. For instance, when Ajax applications are transformed into Web services that are outside the control of the organization, you need to ensure that they can interoperate externally with one another with respect to shared semantics and contractual obligations. Semantic misunderstandings (such as proprietary semantics) and contractual loopholes (such as multiplatform differences) contribute to interoperability problems, such as integrating Ajax applications into legacy systems.
Improvement #2. Web services standards
Let's take a look at several OASIS Web services standards for Ajax applications. (OASIS stands for Organization for the Advancement of Structured Information Standards, directed by the International Open Standards Consortium. See Resources for a link to the site.)
- WS-Security Extensions (WS-SX)
- Security Access Markup Language (SAML)
- Service Provisioning Markup Language (SPML)
- Digital Signature Services (DSS)
- Application Vulnerability Description Language (AVDL)
All of these standards are aimed at reducing the risks for vulnerabilities that have increased as a result of Ajax moving from browser applications to server portals over the Internet. They can work more effectively only if the XOL package or other binary XML schema is applied.
WS-SX
This standard delivers a technical foundation for implementing security functions, such
as integrity and confidentiality in messages implementing higher-level Ajax Web services
applications. Because WSS focuses on a single message exchange, it has been extended as WS-SX to enable trusted SOAP message exchanges involving multiple message exchanges and define security policies that govern the formats and tokens of such messages. Contributing to the development of WS-SX were the Web Services SecureConversation, SecurityPolicy and Trust specifications.
SAML
This markup language defines and maintains a standard XML-based framework for creating
and exchanging security information between online partners. SAML is being used as a Web
single sign-on, an Attribute-based Authorization, and in securing Web services.
SPML
This standard provides an XML framework for managing the provisioning and allocation of identity information and system resources within and between organizations. Additionally, the SPML 1.0 specification has been designed to accommodate the use of WSS, XML Digital Signatures, and XML Encryption.
DSS
This standard defines an XML interface to process digital signatures for Web services and other applications. DSS plays an important role in the security of electronic commerce and other Web applications by assuring the authenticity of Web data when applications are exchanged and retrieved from storage. The DSS specifications include services for signature creation, signature verification, time-stamping, and a combination of the aforementioned capabilities.
AVDL
The goal of the AVDL is to define a language for describing information that can be
used to protect such an application. This information may include -- but is not limited
to -- vulnerability information as well as known legitimate usage information. In Part 7 of my series on using SLAs in a Web services context, I went beyond the AVDL by addressing the issues of interruption thresholds for a Web service that, for example, has not completed the task of responding to a request for vulnerability information over HTTP.
If the time gap is large between a request and a response to the request, interruption
thresholds can reach the level at which they can cause an adverse impact on the SLA
guarantee for uptime availability. To reduce the chances of this adverse impact, the article discussed mitigating the risk of exposing Web services vulnerabilities in a heterogeneous Service-Oriented Architecture (SOA). The impacts of interruption thresholds can be further reduced with the XOL package. This does not imply that the reduction will result in achieving an SLA guarantee.
Improvement #3. Traffic monitoring
Active traffic monitoring is one tool to measure performance of the network traffic of Ajax applications continuously. It can simulate network data and IP services and collect network performance information on Ajax applications in real time. This collection includes data on response time, bandwidth amount, one-way latency, jitter, packet loss, and server response time.
Performance can be monitored for different classes of traffic (such as high, medium, and low priority) over the same connection. By putting the data into a real-time log, you can see where and when excessive packet losses and jitters occur, why slow responses happen, and how changing the priority of applications can improve traffic performance.
Conclusion
You'll need a team of developers, testers, system administrators, and potential users to speed up Ajax applications while dodging Web services vulnerabilities. To eliminate redundancy and memory leaks and reduce the amount of bandwidth and the number of small HTTP requests, you must plan ahead on creating, testing, and deploying Ajax performance improvement projects. Resolving these issues makes your job of speeding up Ajax applications easier.
Resources Learn
- Explore the
OASIS Consortium.
- The
Work
with Web services in enterprise-wide SOA
series by Judith M. Myerson offers information on how to work with Web services in enterprise-wide SOAs.
- Judith M. Myerson's series,
Use SLAs in a Web services context,
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 M. Myerson'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.
- Get the business insight and the technical know-how to ensure successful systems integration by reading
Enterprise Systems Integration, Second Edition.
- Bring your organization into the future with
RFID
in the Supply Chain,
which explains business processes, operational and implementation problems, risks, vulnerabilities, and security and privacy.
- Go into the nuts and bolts of developing a service-level agreement in this IBM Redbook for Domino administrators.
- Visit the technology bookstore for books on these and other technical topics.
- Want more on Web services? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
- Check out the Ajax Resource Center, your one-stop shop for information on the Ajax programming model, including articles and tutorials, discussion forums, blogs, wikis, events, and news. If it's happening, it's covered here.
Get products and technologies
Discuss
About the author  | |  | Judith M. Myerson is a systems architect and engineer. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, security, RFID technologies, and project management.
|
Rate this page
|  |