the web service security threat - CentraleSupélec Metz · Services are standardized, there is...

The Web Services Security Threat

The Risk, The Threats and What You Can Do About It

THE WEB SERVICES SECURITY THREAT WHITE PAPER

Actional Corporation 2

Introduction 3

What are Web Services 3

Calculating Risks of Web Services 4

Background 4

Annualized Rate of Occurrence (ARO) 4

Likelihood of Successful Attack 5

Web Services are Prone to Attacks 5

Diverse Applications Means Diverse Attacks 7

Single Loss Exposure (SLE) 8

Web Services Attacks 10

Examples of Web Services Attacks 11

Buffer Overflow 11

Denial of Service 11

SQL Injection/XPATH/XQUERY Attacks 12

Dictionary Password Attacks 13

Weak Password Attack 14

WSDL Enumeration 14

Routing Detours 15

Malicious Morphing 15

Cross-Site Scripting 16

XML-based Attacks 16

What can be done to protect Web Services 17

Assessing the risk 18

Table of Contents



Even though Web Services standards are only a few years old, the rapid ratification by standards bodies and the committed support by major vendors are unprecedented. Companies and government agencies have been rushing in, with many projects already in production. Security, however, continues to be the leading issue and the top investment area for companies enabling Web Services. Is there a reason for this? Can existing technologies plug these security holes created by Web Services? Are the risks the same for internal and external Web Services? Are the dangers and risks more or less than with existing technologies? The benefits and ease of use make the adoption of Web Services a foregone conclusion. The real question that enterprises must ask themselves when adopting Web Services is: what are the reasonable and cost effective steps to mitigate the risks of Web Services to an acceptable level for our organization?

Introduction

Web Services are a new set of standards and technologies that are making a very significant impact on IT organizations. Web Services usage is predicted to increase rapidly in the next few years through a combination of grassroots development and top-down IT initiatives such as Service-Oriented Architecture (SOA).

There are many definitions of Web Services. Web Services are often described as the set of standards used to provide cross-platform, language independent application communication. It is based on XML standards and is often described as consisting of three main basic standards: SOAP (simple object access protocol), WSDL (web services description language), UDDI (universal description, discovery integration). SOAP, WSDL and UDDI are standards for connecting nearly any type of application. There are many supplemental standards that are in various stages of adoption such as WS-security, SAML, XKMS etc. Many of these are in flux with further iterations being developed.

Web Services operate at the application layer in the OSI stack and are designed to tunnel through port 80 and port 443. Nearly every software vendor has announced support for Web Services standards, including packaged application vendors such as SAP, Peoplesoft, etc., database vendors like Oracle, Sybase and desktop application vendors such as Microsoft. Even legacy mainframe systems have Web Services adapters.

What are Web Services

Web Services are being used for many different types of applications such as for Enterprise Application Integration (EAI), B2B integration and for SOA initiatives. Web Services are being used for small project-level activities to major enterprise-wide architectural changes.

The level of usage of Web Services has been increasing quickly because it is an easy-to-use technology, with a robust set of tools and standards for rapid project results. Physical

Data Link

Network

Transport

Session

Presentation

ApplicationWebServices

This white paper discusses some of the risks associated with using Web Services, particularly with respect to security. It details potential threats and best practices to mitigate these risks.



There are many methods for calculating security risk. Calculating risk around Web Services is difficult given that Web Services can be used for many different types of applications. Web Services can be used for simple enterprise application integration to complex B2B communication with partners and other third parties. We will examine one method by which to examine the security risk of Web Services.

What are the risks to Web Services

The goal of Web Services is to expose standardized interfaces to new and existing applications. No technology in the past has created such potential exposures to critical business applications. Web Services are standardized interfaces and therefore can be attacked in consistent ways. Hackers can more easily gain access to a standardized interface than a proprietary interface because more is known about the interface.

In addition, the adoption of Web Services has been increasing rapidly. While it has not hit the mainstream yet, all analyst predictions point to massive adoption in the coming years. Support in the vendor community has been growing faster providing further impetus for rapid growth.

In assessing the basic security risk of using Web Services, one must examine a couple of key areas. There are many ways to analyze security risk. One simple way is to look at the following formula:

Background

Each organization has different ways of calculating these variables. To illustrate, we’ll discuss each of these variables.

Annualized Loss Expectancy = Annualized Rate of Occurrence x Single Loss Exposure

One constant in the security realm is that companies and government agencies must expect to be attacked. Large organizations are attacked on a regular basis through ever new and creative means. In the recent 2004 Computer Security Institute and FBI survey, 100% of companies experienced attacks.

For externally facing Web Services, access to interfaces is simple. Because Web Services are designed to tunnel through existing network firewalls, hackers can quite easily get direct access to applications. In addition, because Web Services are self-describing, with WSDL’s that describe how to interact with Web Services, hackers have more information than ever on how to interact with specific application interfaces.

Many Web Services projects are internally focused which might provide a false level of comfort to security professionals. In the CSI/FBI study, almost 50% of security breaches were from internal sources. Whether it’s a recently fired employee or an unscrupulous trader or a compromised partner, there is significant risk from the inside. While there are varying statistics, internal attacks may be considered more harmful because the attacker typically has much more inside knowledge of the systems to cause the most damage while greatly reducing the chance of being detected.

Annualized Rate of Occurrence (ARO)



Web Services are in the early stages now but in some surveys, over 60% of companies have Web Services already in production. Many of these implementations are grassroots efforts that escape the radar screens of the network operations and security staff – and therefore their policies. Existing technologies are neither XML-aware nor provide the proper enforcement protection increasing the security risk.

Measuring the likelihood of successful attack is very difficult. The most recent CSI/FBI report on Cyber Security (2004) reported that 53% of survey respondents were successfully breached with a cost of damage in excess of $500,000 per incident. The actual percentage could be much higher due to many companies’ reluctance to reveal security information. In fact, 48% of respondents did not report breaches in general fearing leakage of information.

What can be safely said is that a majority of companies were successfully attacked against their existing technologies and protections. Web Services provides new conduits for attack and therefore will have a higher percentage of successful attack. Web Services are essentially standardized interfaces or API’s into many different types of applications. These applications are not protected in a consistent way, nor are existing technologies such as SSL and network firewalls prepared to protect them. In fact, a recent Gartner Group report stated that

“Web Services will reopen 70% of attack paths closed by network firewalls.”

A recent IDC study found that security topped the list of Web Services software that companies would invest in. Over 70% of respondents in this May 2004 survey said that they planned to invest in security software for Web Services.

Likelihood of Successful Attack

Web Services are a new set of standards with relatively new vendor implementations. There are many reasons why Web Services are prone to attack.

First of all, Web Services are a new type of interface or API to existing and new applications. Because Web Services are standardized, there is little “security through obscurity.” There is very little proprietary about Web Services which greatly ease the access and consistency of access of Web Services. In addition, Web Services are human readable and self-describing. SOAP messages provide information and structure for each message. WSDL documents provide significant information about each Web Service, including where the service is, how to access it, what kind of information to send to it and what type of information you should expect to receive back. In some cases, it may reveal the tool that generates or hosts the Web Service. This provides significant information to a potential intruder to inappropriately access the service.

One might incorrectly assume that because Web Services are mostly intended for programmatic access that there is some security through obscurity or that the average end-user cannot access them. This is entirely incorrect. Microsoft Excel is an example of a tool everyone has that enables any user to easily communicate with a Web Service. Many user-friendly GUI-based tools can be downloaded to find, bind, analyze and exchange information with a Web Service. These tools enable an attacker, without any programming experience to easily play around and hack into a Web Service interface. Some of these tools can even SSL to a Web Service.

Web Services are Prone to Attacks



Web Services traffic also tunnels through port 80 and port 443. Existing tools such as network firewalls provide little protection against Web Services traffic. They may provide some simple filtering capabilities but cannot provide consistent protection across a diverse set of Web Services. IDS systems can also catch some specific attacks and viruses but does not provide specific protections against XML-based attacks. Application firewalls typically provide protection only against HTML and browser-based attacks and not against the XML message stream.

SSL is part of an overall solution recommended by many companies and analysts but does not alone have the visibility in the message to provide the proper security to mitigate risks. Web Services requires granularity on encryption. For example, encrypting sensitive information while exposing routing information in clear-text. This is the reason why the XML Encryption, XML Signature and WS-Security standards were invented and ratified. Viruses and other malicious XML can just as easily be transported encrypted as in clear-text. In fact, it can be harder to detect a compromised SSL connection because it is passing encrypted attacks.

SSL is a good technology for protecting pipes between machines. SSL should be used in conjunction with other security mechanisms to provide transport-level security for Web Services but it is neither purpose-built nor adequate for most security for Web Services. SSL and IP filtering operate on the machine level, providing only a clumsy level granularity for securing Web Services. It does not provide application or user-level authentication or authorization capabilities nor provides encryption and non-repudiation at the element level. Below are some of the reasons why SSL is not recommended as the only solution for securing Web Services.

First of all, SSL can be expensive to provision. Managing the environment and procuring the technology for every single possible requestor and Web Service combination is a definite challenge and a significant cost. Some Web Services may have hundreds and thousands of different requestors. If you were using, for example, mutual SSL, managing the keys across a diverse set of participants would be costly from a management standpoint and represent a potential security risk.

It is possible that SSL can be compromised but the likelihood is dependent on the key sizes being used. What is more common is not automatically checking revocation lists (CRL’s) whereby the termination points do not check for expired and revoked keys. Many Web Services are also stateless. Creating and tearing down SSL connections for every single message can cause performance problems. In addition, encrypting the entire message can be less efficient than encrypting just specific portions of the message that truly need to be encrypted.

Another important deficiency is that SSL only protects the transport between two computers or devices. If any of the endpoints or intermediaries (such as routers) are compromised, then transport security provides no protection against attacks sent from a compromised machine. Compromised endpoints (often caused by a host-level break-in) can occur for a number of reasons. A disgruntled employee, a recently fired worker or someone who simply wants to take advantage of the system can easily use their knowledge to compromise a machine and perform malicious actions that are very difficult to track with no other checks and balances in place. With only SSL or IP filtering protection, a compromised machine can be used to attack any Web Service that that machine has access to.

Because Web Services are often used (or planned to be used) in external environments such as B2B communication or across firewall communication, there is a reliance on external parties and their security capabilities. If a partner’s machine is compromised, then SSL provides a convenient pipe for an outside hacker to attack your systems. Relying on the security mechanisms of an entity outside your control is a major security risk and is obviously not a recommended practice.



Stored as Clear text

DBSSL SSL

Encryptedattack

Figure 1: SSL provides some additional protection for Web Services but is not recommended as the only security solution. For instance, SSL only protects the pipes and provides no protection against host-level or intermediary break-ins. An attack can be sent through encrypted channels just as easily as through clear-text channels but are harder to detect. SSL only provides point-to-point transport protection leaving sensitive information in clear-text outside of the channel. SSL is also rather inefficient in that it encrypts the whole message, not just the parts that require encrypting and is also required for every connection point.

Not all endpoints will necessarily support SSL. Given the types of endpoints such as desktop applications like Mi-crosoft Excel or even wireless applications like phones, many of these are more likely to support XML Encryption, XML Signature and more granular forms of authentication for communication than SSL.

Any type of application can be behind the Web Service interface. They range from packaged applications such as SAP and Peoplesoft to internally developed applications like J2EE and .NET developed programs to desktop applications. Legacy applications like mainframes can also be exposed via Web Services. These applications obviously carry their own security vulnerabilities which are likely to be even more exposed via Web Services interfaces. In addition, they all approach security in different ways. This presents a significant security challenge to protect these services consistently.

Diverse Applications Means Diverse Attacks

■ New type of interface • Web Services is human readable and self-describing • SOAP, WSDL can reveal tools that generated it ■ Applications behind service may be unprepared • Tunnels through HTTP and port 80. • Legacy apps like mainframes, desktop apps, etc. are ill prepared • Lack of consistency in back end applications • Many different types of applications each with their own vulnerabilities ■ Existing security mechanisms don’t secure these attacks • App firewall filtering protects only HTML traffic • IDS systems catch specific app attacks • Network firewalls catch only network attacks ■ Similar results from developer mistakes or bad programming

Fig. 2 Reasons Why Web Services Are More Prone to Attack

Because Web Services are easy to access and relatively easy to compromise, the likelihood of successful attack is quite high.



Costs per attack are highly dependent upon the nature and type of applications under scrutiny. When assessing risk, one must look at the value of the assets at risk. Web Services can wrap nearly any type of application, and the value of information in an Excel spreadsheet tracking customer data may be just as valuable as the information stored in an SAP system. To assess the value of the information one must consider the costs of the information being erased, being corrupted, being compromised or being leaked to the press or competition.

Costs for attacks range across the board and can be highly measurable or highly subjective. Some costs are immediate and some costs recur for years.

Single Loss Exposure (SLE)

DowntimeTransactional theftPolitical damagePersonal safetyCost to diagnoseCost to fix damaged systemsCosts to recover information

DowntimeTransactional theftPolitical damagePersonal safetyCost to diagnoseCost to fix damaged systemsCosts to recover information

Hard Costs

Negative publicityCost of damage controlManagement distraction

Loss of reputationLoss of employee moraleAdvantage to the competition

Soft Costs

Short Term Medium TermSecurity Incident

Below are some common costs to consider and some examples of how these costs can be damaging

Cost of Security Incident Description Example (s)

Discontinuity in business

Security incident can cause disruption in business service resulting in downtime, poor response times, lost transactions and poor customer service

• Every minute of downtime for an e-commerce application, customer or internal transactional portal can be quantified in terms of lost transactions

Transactional theft Security incident can result in stolen funds or goods

• Funds can be improperly redirected to an illegal account • Account balances can be illegally modified• Products can be improperly delivered

Personal safety Disruption to life-dependent systems can cause people’s safety to be compromised

• Disruption to a 911 call center or to a hospital’s systems can cause loss of life • Military systems can reveal compromising information to enemy forces• Traffic control systems, navigation systems, etc. can be interfered with



Cost of Security Incident Description Example (s)

Political effects Compromising government systems can cause significant political damage

• Government systems can be compromised causing leakage of sensitive information

Regulatory requirements

Noncompliance with regulatory regimes may result in monetary damages and jail sentences

• A compromised database of names can result in a loss of privacy against the EU Privacy Directive• Sarbanes Oxley breach of information can result in regulatory fines

Punitive damages and lawsuits

Lawsuits may be brought upon the company by shareholders, customers, etc. due to security mismanagement

• Patient whose confidential information has been compromised may have legitimate legal claims • Breach in credit card database can cause significant monetary damage

IT costs to diagnosing and fixing security incident

People and tool cost to diagnose problem and fix problem

• Tracing and fixing problem can take hours and days to locate problem and to provide a short and medium term fix

Embarrassing publicity, negative media

Cost of dealing with negative media includes additional public relations fees, cost of management time to deal with incident

• A new California measure requires all security incidences to be publicly reported• Extra PR fees and management time required to publicly handle incident• Negative product and service reviews

Loss of reputation Damage in reputation, being known as a company with lax security

• Company with credit card and account information compromised loses trust from consumers

Loss of employee morale

Loss in confidence of IT organization and credibility to the rest of the organization

• A successful attack against the IT organization can cause sales and executives to lose confidence and trust in the IT organization

Lower stock price Perception of “problems” in the IT organization can lower value by investors

• A mishandled attack can result in lower investor confidence and lower stock prices• In a recent congressional report (04/1/2004) analysts had found that target firms suffered 1%-5% stock price declines in the days after an attack

In the most recent CSI/FBI Report on Cyber Security (2004), they reported that each security incident was in excess of $500,000 per incident. This represented mostly hard costs and not soft costs which would likely add significantly more impact.



Assessing the Risk of Web ServicesAnnualized Loss Expectancy = Annualized Rate of Occurrence (ARO) X Single Loss Exposure (SLE)

■ Cost per attack is in excess of $500,000 not including soft costs■ Likelihood of successful attack is greater than 53%■ Reported attacks are equally split between internal and external compromises■ Frequency of attack is low today but is predicted to increase rapidly, particularly as Web Services adoption proliferates. Given that 100% of companies are under attack today is a good indicator of predicted Web Services attacks.

Fig. 3 New technologies like Web Services have higher risks than existing technologies. While frequency of attack is currently fairly low, it is predicted to increase rapidly. The key issue is that without the right tools, the likelihood of successful attack is high.

The key issue is that if you are using or plan to use Web Services, your organization will be subject to attack. The success rate of these attacks will depend upon the proper tools and procedures you put in place. Use of only existing technologies greatly increases the chance of a security risk. Use of the proper tools and procedures to specifically deal with Web Services security will decrease the likelihood of successful attack.

There are many ways to attack Web Services. In this paper we will cover some of the basic ways that this can be accomplished. Some of these are new flavors of attack that can be utilized on these new types of interfaces. Others are rather new and can take advantage of new and immature technologies to gain unauthorized access or cause disruption.

There are many ways to classify these attacks. One way to classify them is below:

Web Services Attacks

XML-based attacks Taking advantage of the way XML works. For instance, an XML document can be sent that causes a large entity expansion, tying up system resources.

Bugs in back end systems

Many technologies are used in the XML message stream and can include XML parsers, application servers, operating systems, databases, etc. XML can encapsulate malware that can take advantage of bugs in these systems

Code injection attacks Attack code can be sent via a SOAP message to be later executed in a receiving application. For instance SQL injection or cross-site scripting attacks are relatively easy to create.

Content-based attacks Viruses, overly long strings, large messages, malformed messages are examples of attacks that can cause unexpected behavior at the receiving application

Denial of Service A flood of messages, or a message with hundreds of encrypted elements may cause systems resources to be tied up and service levels to be affected.

Man in the middle attack

Messages can be intercepted to cause routing problems or integrity problems. This can cause a receiving application to be disrupted or to be illegally accessed.



Below is just a partial list of Web Services attacks that are possible against XML Web Services. We provide descriptions of each attack so that you can be aware of the types of risks that are associated with using Web Services.

Examples of Web Services Attacks

In a buffer overflow situation, an overly long input string may not be gracefully handled by the receiving service or application behind the service. Buffer overflows can be on a particular element or field or on the message as a whole. If the receiving system is not prepared to handle unexpected field and message lengths, the application may be compromised. The application may crash, causing access to the system or possible downtime.

Buffer Overflow

Web Service

<SOAP-ENV:Header /> <SOAP-ENV:Body>

<parameter1>a;slkdjfS%^a;sdkfGFdkfja;sldkjf;ajkfna;dfjnagfghrdfgsecurityjryhj&twlbuyxmsKJLKfweDwdfdseydfdfgsfdgf%$$ewefnjoisddffjdsafastodifjnsoifjea;lisj;f;ankdlnbl;kjspeed;lsdsdkvja;lsdkxmslrobustsldkfja;ldskldskfjdfaserweraeffhkmeHFdkgjsdkkiJHkdfjsleiL …

Fig. 4: A large value is placed in parameter1 and sent to a receiving application that may not be prepared to handle an overly long string

There are many types of denial of service mechanisms. The most common form of Denial of Service attack is to simply flood a system with more messages than it can handle. This can cause severe disruption to a system. Note that there are many other ways to perform denial of service attacks. A hacker can send very large attachments, or send overly long messages. Another interesting form of denial of service is to send a message with many encrypted elements or signed elements. Because cryptographic operations such as encryption and signing require significant processor resources, a service can be tied up handling these types of malicious messages.

Denial of service almost always results in unavailable systems. It can also result in systems crashing. Lost transactions as well as system integrity issues can be highly costly to fix.

Denial of Service



Web Service


<CustomerData>

<EncryptedData Type=’http://www.w3.org/…> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherData></EncryptedData>

<EncryptedData Type=’http://www.w3.org/…> <CipherData> <CipherValue>A23B4DFS56</CipherValue> </CipherData></EncryptedData>

…

</CustomerData> </SOAP-ENV:Body></SOAP-ENV:Envelope>

Repeated Hundreds of Times

Figure 5: A message with a large number of encrypted elements is sent to overwhelm the processing of the receiving application and cause a denial of service.

Code injection attacks are relatively straightforward and usually require some knowledge of what the back end system is behind the interface. Many Web Services provide queryable information and have a SQL database in the backend. A Web Service can be quite easily compromised by sending code fragments within the envelope of Web Services. When the code fragment is unwrapped and sent to the database, special characters may cause unintended SQL, XPATH and XQUERY statements to be executed. This can cause unauthorized access to systems, or access to information that was not intended to be seen. More malicious forms of injection attacks can cause unwanted commands or code to be run such as to delete an entire database table.

SQL Injection/XPATH/XQUERY Attacks



Web Service

SQLDatabase


<Login> a’ OR ‘a’=’a</Login><Password>a’ OR ‘a’=’a</Password> </SOAP-ENV:Body></SOAP-ENV:Envelope>

SQL Statement

SELECT ‘authenticated’ FROM password table WHERE login=‘a’ OR ‘a’=‘a’ AND password= =‘a’ OR ‘a’=‘a’;

Other SQL Statements thatcan be easily created

• Returns the whole customer table:

SELECT account_balance FROM cust_tableWHERE accountid=‘a’ OR ‘a’=‘a’;

• Deletes the table

SELECT price FROM price_list WHERE product=‘a’; DELETE FROM price_list WHERE 1=1;

Figure 6: In this example, a password table is compromised by simply resolving the authentication string to always be TRUE. This enables simple authentication to the system. Other SQL Injection statements can cause unauthorized access to information or to simply delete the entire table.

Dictionary password attacks are a common way to attempt to gain access to a system. By repeatedly trying very common usernames and password combinations, systems can be compromised because many administrators pick weak username and password combinations. This can result in unauthorized access to systems.

Dictionary Password Attacks

Web Service


<Login>scott</Login><Password>tiger</Password> </SOAP-ENV:Body></SOAP-ENV:Envelope>


<Login>guest</Login><Password>welcome</Password> </SOAP-ENV:Body></SOAP-ENV:Envelope>


<Login>system</Login><Password>manager</Password> </SOAP-ENV:Body></SOAP-ENV:Envelope>

Figure 7: Various common password combinations are repeatedly tried to gain access to the backend system. SCOTT/TIGER for instance is a common demo username/password for Oracle databases.



Enforcing strong password policies is common in many organizations and is often a regulatory requirement. Regardless of policy, it is also common that administrators pick weak passwords. This can cause access to systems using trial by error or brute force dictionary password attacks.

Weak Password Attack

Web Service


<Login>guest</Login><Password>hello</Password> </SOAP-ENV:Body></SOAP-ENV:Envelope>

Password may not fulfill requirements:

Total char >= 6At least 1 numeric

Figure 8: Weak password enforcement policies can result in weak passwords being chosen providing attackers an easier way to access systems.

Web Services is a self-describing set of standards which allows access to significant amounts of meta information to aid seamless communication. This also means that there is a lot of information available to attackers of Web Service systems. In this example, the WSDL file contains significant information as to where a particular service is, what types of functions are callable within the Web Service and how to interact with such a service. The WSDL is essentially an advertising mechanism that can reveal information such as a sensitive service or an important parameter. WSDL may also reveal what tools generated the Web Service providing attackers with more information on the environment.

WSDL Enumeration

Web Service

GetQuoteTradeStock

WSDL

<operation name=”GetFundQuote”> <soap:operation soapAction=http://www.bank.com/GetQuote style=”document” /> … </operation> <operation name=“TradeStock”> <soap:operation soapAction=http://www.bank.com/TradeStock style=”document” /> … </operation>

Figure 9: The WSDL reveals several callable operations, most notably GetQuote and TradeStock. In this situation, you may wish everybody to have access to GetQuote but only a certain subset of requestors who are authorized TradeStocks. Even with authentication and access control, the WSDL may reveal information about TradeStock than is desirable.



Routing Detours are a form of a “Man in the Middle” attack which compromises routing information. Intermediaries can be “hijacked” to rout sensitive messages to an outside location. Routing information (whether in the HTTP headers or in WS-Routing headers) can be modified enroute . Traces of the routing can be removed from the message so that the receiving application does not realize that a routing detour has occurred.

Routing Detours

Web Service

Traces of maliciousrouting can be removedfrom the message

SOAP

<wsrp:to>SOAP://endpoint.com</wsrp:to><wsrp:fwd> <wsrp:via>SOAP://intermediary1.com</wsrp:via> <wsrp:via>SOAP://MALICIOUS.com</wsrp:via> <wsrp:via>SOAP://intermediary2.com</wsrp:via></wsrp:fwd><wsrp:from>SOAP://origin.com</wsrp:to>

Route changedto malicious intermediary

Figure 10: An intermediary is compromised which modifies WS-Routing headers to send sensitive information to an outside server. The information is either routed back to the intermediary or to the Web Service with all traces removed.

Malicious morphing is another form of “Man in the Middle” attack. Data, security information can be modified enroute by an attacker resulting in data integrity issues and operational problems.

Malicious Morphing

Web Service

SOAP

<purchase_order></purchase_order>

<destination_address> 1234 Main Street

New York, NY 10000</destination_address>

Data changedto different

address

Figure 11: A compromised intermediary may modify the destination address of a purchase order or modify funds balance of a transaction to affect the data integrity of a back end system.



SOAP and XML are standards used to wrap data for easy consumption. SOAP provides enveloping information to deliver messages in a seamless fashion between heterogeneous applications. XML includes metadata to describe the structure of the information. Malicious code can be embedded into the elements or CDATA of the information. CDATA is used to delineate information in the message that should not be parsed. Embedded characters or malicious code can be sent. The receiving application may display or execute the data in unintended ways. Cross-site scripting (sometimes called XML encapsulation) can be used to embed commands that can tie up system resources or gain unauthorized access.

Cross-Site Scripting

Web Service

SOAP

<RegisterUser> <Name>

<![CDATA[ <script>

While (true) {} </script>

]]> </Name>

1. Data modifiedto store a script

into a field value

Portal

Database

2. Script stored indatabase field

3. When field valueis to be displayed

script runs causinginfinite loop

Figure 12: Illegal javascript code is injected into a message using CDATA. The field value, which eventually is displayed in a browser, actually runs javascript code on a browser causing an infinite loop

Sometimes called “Coercive Parsing”, XML-based attacks take advantage of the XML parsers that process the SOAP message. Web Services and existing infrastructure do not provide protection for XML-based attacks. Putting in recursive relationships to create entity expansions, bogus parameters and significant amounts of whitespace can cause XML parsers to be overloaded or to perform unexpected problems. A recent Oracle Application Server bug for instance allowed for DTD references in a SOAP message which the standard does not allow. This would enable circular DTD references to be made causing resources to be tied up.

XML-based Attacks

Web Service

SOAP

<RegisterUser> <Name> </Name>

<Address> </Address>

….

Whitespace andlarge # of parameters

can overwhelm processing

Figure 13: Malicious content can be sent taking advantage of deficiencies in XML parsers.



The ten examples that were described represent a small subset of the possible attacks against Web Services. Very few of these attacks would be caught by typical standard security tools.

As is the case with most applications, Web Services also requires standard security functionality to provide protection. These requirements often include:

What can be done to protect Web Services

Authentication Verifying the identity of the requestor

Access Control Ensuring that the requestor has appropriate access to the resource

Encryption Ensuring end-to-end data privacy. Support for both SSL and XML Encryption are essential

Signing Ensuring message integrity. Support for XML Signature

Schema Validation Ensuring integrity of the structure and content of message

Support for security standards Supporting standards based security functions such as WS-Security for interoperability and future security protection

Malicious attack protection Supporting protection against the latest Web Services and XML-based attacks

Data collection Audit data is crucial for identifying and diagnosing attack as well as proving compliance

Service virtualization Hiding details on back end resources and sensitive services from view

Automated threat response Having the ability to respond to threats in an automated manner and to alert the right people as necessary

Fail negatively Only allowing named traffic to pass and in the event of a system failure, failing negatively

Integration with existing security environment

Allowing policy and functionality from existing security infrastructure, such as identity management solutions, PKI infrastructure and network management and monitoring tools to be leveraged

Security protection is required across all Web Services traffic and must be applied in a consistent manner regardless of the different types of technologies being connected in the Web Service network.

Many companies are turning to dedicated technologies that specifically deal with these threats in order to provide the necessary insurance that security will not ruin their projects. Technologies such as Web Service Security Gateways or XML Firewalls provide protection that spans across all Web Services regardless of the underlying technology. Some Web Service security vendors provide Web Service endpoint technology to provide protection at the actual Web Service. Others offer hardware solutions and others provide software solutions. A few vendors provide all of these options which enable the broadest range of security protection and cover the variety of implementation requirements necessary for most IT environments.



Gaining knowledge of the assets being protected as well as the nature of attacks against Web Services will help you assess the risk of introducing new technologies. Most analysts and companies agree that Web Services traffic is not a large amount of their traffic today but predict that it will be significant very rapidly. Because security is the top of mind for any Web Service project, many companies rightfully are architecting a scalable security infrastructure as their first step. Security is a hot button issue for any company today due to heightened levels of security and the increasing specter of costly regulatory fines and imprisonment. Ensuring the security of your Web Service project is a critical element to ensuring the success of your projects.

Assessing the Risk

800 W. El Camino Real, Suite 120Mountain View, CA 94040 Phone: 650-210-0700 Email: [email protected]: www.actional.com

To find out more about how Actional can secure your environment, please visit: www.actional.com

As the leading provider of SOA enablement solutions, Actional Corporation addresses the specific challenges of securing, deploying and managing service-oriented environments, from early Web services projects to enterprisewide SOA initiatives. The company’s sole mission is to keep customers’ SOAs secure and operational 24/7, making Actional the choice of leading organizations around the world including Danish Immigration Service, Partners Healthcare, Thomson Prometric, MCI, Telstra, Travelers, the U.S. government, and others. With Actional’s SOA Command and Control Platform, customers can reduce costs and ease the complexity of SOA deployments, thereby increasing the responsiveness of IT, accelerating time-to-market of business-critical applications and capitalizing on the business value of their SOA. Actional, which recently merged with Westbridge Technology, is a privately held company based in Mountain View, Calif.

About Actional Corporation

© Copyright 2004 Actional Corporation. All rights reserved. All other product names are trademarks of their respective owners. wsstWP1004

mailto:[email protected]

http://www.actional.com

http://www.actional.com

Date post:	22-Sep-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

the web service security threat - CentraleSupélec Metz · Services are standardized, there is...

Documents