7.4 Web Services Security Requirements

Security sometimes is an afterthought until something unpleasant happens or a security loophole is reported . Security is a process. The security requirements are the key drivers for the Web Services security framework. They relate the security concerns to different areas of Web Services technology during the initial design and implementation stage. It would be useful to put these requirements into scenarios to get the appropriate perspective.

Authentication. The client accessing the business services, which may be a Web browser, PDA, or WAP phone, needs to be authenticated with reliable credentials. Reliable credentials may be passwords, X.509v3 digital certificates, Kerberos tickets, or any secure token and are used to validate the identity of the Service Requester. This is paramount to Web Services because the business services, which are provided by a third party or a remote Service Provider from overseas, may incur high monetary value payment transactions using credit cards.

Authorization/Entitlement. Upon successful authentication, a client requests access to business services, whether locally or remotely. Because Web Services are "programmatic" interfaces, they are harder to monitor for suspicious activities. Therefore, it is crucial that there is proper access control for each business service invoked. In other words, each network identity should be entitled with access rights for the local or remote service and the access level of the Service Requester checked against a list of resource access rights at run time. The access request can be granted and the Web Services invoked upon successful authorization, or denied if insufficient access rights are identified.

Traceability. Each transactional Web Services call should be logged at the level of Web Services invocation and transport layer. This is in addition to the transaction log taken by the local or remote applications. In such a case, administrators can track and trace the service request at different points within the life cycle. For example, the HTTP/S activities can be tracked from the Web server's audit and log, and the XML-RPC SOAP calls can be traced from the SOAP server log.

Data Privacy and Confidentiality. Data privacy keeps information confidential, so that only the data owner and the target recipient are able to read it. Data privacy and confidentiality is usually accomplished using encryption. Web Services technology should be able to accommodate different encryption mechanisms (such as RSA-MD2, RSA-MD5, SHA, and NIST) with different key length (which may be subject to some countries' export regulations ”for example, 128-bit encryption key for SSL may be restricted to certain countries ).

Availability/Denial of Service. Denial of Service is often employed to attack Web sites and business services that have sophisticated security features. However, no matter how sophisticated these business services are, they may still be vulnerable to a Denial of Service attack. It is useful to profile the loading and capacity for each Web Services call so that appropriate preventive measures, such as load balancing, packet filtering, virus checking, failover, or backup, can be designed to protect from any potential Denial of Service.

Data Integrity. Transactions and private data, if transmitted in XML clear text, may be intercepted, modified, or tampered with. The use of different encryption mechanisms can protect the data from retrieval. However, if the keys are compromised, then a middleman or a replay attack may tamper with the data. Thus, in addition to encryption, checksums and MAC'ing, as part of the XML elements, are good tools to support data integrity.

Non- repudiation . Increasing cross-enterprise data exchanges and B2B integration would require support for non-repudiation. It has a legal implication . Digital signature using digital certificates (such as PKI X.509v3) or Kerberos tickets (such as Microsoft PASSPORT) is a key element to provide non-repudiation. Non-repudiation enables users to prove that a transaction has been committed with valid credentials. This prevents any trading partner from claiming that the transaction never occurred. The support of non-repudiation requires logging details of the transactions at each point of exchange (including the application server at both ends), digital signatures along with the transactions, and a mechanism that ensures the logs and credentials are authentic .

7.4.1 The Big Picture

To get the big picture of end-to-end Web Services, it is important for us to understand the security stack of Web Services technology, the security characteristics of each layer, their potential point of attacks, and examples of the commercial implementation. Next , it is important to understand how trust models are built and the related threat profiling, where we can design risk mitigation mechanism.

Web Services Security Stack

The security stack shown in Table 7-1 is ideal for designing Web Services applications. The approach to protecting Web Services security involves using different security technology and tools at each layer.

Table 7-1. Web Services Security Stack

	Security Mechanism	Examples of Security Protection	Security Standards Specifications
Service Negotiation	Identity management Access control and policy management Single Sign-on	Liberty-compliant Identity Server Access control for XML messages Single Sign-on products	Identity management ” Liberty 1.1, XML Key Management Specification (XKMS), WS-Federation Entitlement ” SAML, XACML, WS-Authorization Policy ” WS-Policy Others ” WS-Secure Conversation, WS-Trust, WS-Privacy
Service Discovery	Service Registry security	UDDI Service Registry security features Protection for WSDL documents	UDDI WSDL
Transaction Routing	Messaging security	Data encryption Digital signature Key management and managing credentials	XML Encryption (XML-ENC) XML Signature (XML-DSIG) WS-Security XKMS
Transport	Data transport security	128-bit SSL with HTTPS Protocol security for FTP, SMTP, and so forth	HTTPS HTTPR IPSec
Internet	Network connectivity security	Leased line or router-level encryption Virtual Private Network (VPN) gateways
Platform	Operating system security Penetration testing Key exchanges between hosts	Solaris OE hardening Linux Operating System (OS) hardening Windows OS hardening Professional Penetration Testing

Platform Security

The platform security is essential to protecting the Service Provider and the Requester (Consumer). This is often the target for security attacks or exploitation ”for example, a Denial of Service attack for SOAP servers may result in no service available even if the back-end applications are still running. To mitigate the platform security risks, architects and developers may use Operating System security hardening and penetration tests to secure the platform.

Internet or Network Layer Security

The Internet layer is using the TCP/IP protocol. A Virtual Private Network (VPN) gateway is one common way to protect Web Services applications deployed using the public Internet. This is in conjunction with using HTTPS and SSL for secure tunneling between the client and the server. Both trading partners need to establish a VPN tunnel.

Transport Layer Security

HTTPS is an authentication protocol using a secure tunneling between the client and the server. It encodes the transmissions between the client and the server using Secure Sockets Layer (usually 128-bit SSL). As HTML form-based authentication passes user id and password information in clear text, the use of HTTPS addresses the security issue of passing such data in clear text over HTTP. Often, Web Services applications are distributed, and HTTPS alone will not be sufficient to protect distributed Web Services from end to end. HTTPR is a specification from IBM to provide guaranteed message delivery of SOAP messages over HTTPS ( http://www.106.ibm.com/developerworks/ webservices /library/ws-phtt/ ). It was not submitted to W3C, but it was being discussed under W3C Web Services discussion forum. The ebXML Message Service ( http://www.ebxml.org/ specs /ebMS2.pdf ), which uses SOAP messaging as the transport and routing layer, is another initiative that provides reliable message delivery over HTTPS.

IPSec is another security protocol on top of TCP/IP that protects the IP connectivity between the client and the server at the IP data-packet level. This provides additional transport-layer security, in conjunction with HTTPS. Most operating system platforms, such as Windows 2000/XP and Solaris 8 OE, have built-in IPSec today.

Another useful security protection in conjunction with the network layer is host security hardening. This ensures the network services of the host infrastructure can be hardened and secured.

Transaction Routing

XML encryption, together with digital signatures, is a key means to protect sensitive data during message routing. Users can sign before they encrypt data or encrypt data before they sign. There are a few encryption algorithms supported, such as block encryption and chain mode. XML encryption and digital signatures are covered in both XML-ENC and WS-Security. There are commercial implementations of these standards, including IBM's XML Security Suite, Baltimore's Keytools, Microsoft's CAPICOM, and Sun's J2SE 1.4 security features (JCE, JSEE, Java CertPath, JAAS, and JGSS).

Service Discovery

Web Services are discovered and bound to Web Services Description Language (WSDL) at run time. Many commercial implementations of the Service Registry use LDAP (for example, Sun ONE Registry Server) or RDBMS (for example, IBM UDDI), which require access rights for read access or administrative update. None of the service information is stored in clear text. Web Services can be discovered using a WSDL file, without UDDI. However, WSDL files are often stored in clear text and may be another target for attack. This needs to be addressed by security hardening of the host and a file-protection mechanism.

Service Negotiation

After service discovery, Web Services are negotiated and invoked upon successful authentication. XKMS is one important security initiative to support a managed trust service (key management and identity authentication outsourced to an external trusted authority), as well as a home-grown trust service (customers performing authentication and key management). The security risk will be dependent on the trust level and reliability of the external or internal Trust Authority. Examples of XKMS implementation include VeriSign's Trust Services Integration Kit.

Upon successful authentication, Web Services Service Providers will retrieve the access rights and profile for the Service Requester. SAML and Liberty are cross-enterprise Single Sign-on technologies that enable easier integration between trading partners, independent of the network identity management infrastructure or entitlement service technology used. XACML provides a fine-grained access control capability of the XML data contents. However, without encryption, the SAML and XACML files are in clear text and may be another target of attack.

Figure 7-1 depicts a scenario, using security techniques just discussed, in which a Web Services call requires different layers of security. Both the Service Requester (client) and the Service Provider (server) are assumed to have their platforms secured with operating system security hardening. This refers to the platform security. The following processes illustrate that a Web Services call needs to have different security mechanisms in place to enable end-to-end Web Services.

Figure 7-1. Web Services Security Stack Process

A Service Requester is connected to the Service Provider via a VPN over the Internet. The VPN makes use of the IPSec protocol to secure the connection between the client and the server (step 1). This refers to the Internet or network layer security. The client also uses HTTPS to secure the connection between the client browser and the server using a 128-bit SSL certificate (step 2). The use of HTTPS with SSL should safeguard the client session. This refers to the transport layer security.

Using a secure HTTPS connection, the client browses various business services from a UDDI Service Registry. It finds the relevant business service, and retrieves the service end-point URL (step 3). This refers to the service discovery security.

Upon invoking the business service, the Service Requester (the SOAP client) needs to provide user credentials in order to authenticate himself/herself for using the remote Web Services. The Service Provider is part of a Circle of Trust that is managed by an external Liberty-compliant Identity Provider, which provides an authentication service using the XML Key Management Specification. The client's key is located from the trust authority via XKMS (step 4). The Service Requester then provides a user id and password to authenticate himself/herself. Upon successful authentication, the Identity Provider enables Single Sign-on for the Service Requester using SAML and XACML protocols (step 5). Thus, the Service Requester does not need to log in again to use other Web Services. This refers to the service negotiation security.

When the Service Requester invokes a Web Service, the client side makes use of the public and private keys using XKMS to encrypt the data content in the SOAP message (XML Encryption) and to generate a digital signature (XML Signature) to attach to the SOAP envelope. WS-Security is a message-level security to protect SOAP messages. It is built on top of the XML Encryption and XML Signature specifications. In such a way, the service request and the data content in the SOAP messages are secured by using the WS-Security specification (step 6). This refers to the transaction routing security.

7.4.2 Web Services Security Framework

An end-to-end Web Services implementation not only makes use of encryption and digital signatures appropriately for transactional security, it also requires a structural framework so that none of the development and implementation aspects are missed. There are four key concepts that can describe an end-to-end Web Services security framework: Identity, Trust, Policy, and Threat Profiling. Figures 7-2 and 7-3 relate these concepts in the context of the interaction between Service Requesters, Service Providers, and Service Brokers.

Figure 7-2. Web Services Security Framework in the Context of Web Services Interaction

Figure 7-3. Web Services Security Framework With Details

Figure 7-2 depicts a similar scenario to Figure 3-3, where a Service Requester (supplier or buyer) is invoking a remote business service from a Service Provider or a Service Broker in a Business-to-Business (B2B) marketplace. The security concerns for the B2B market are the identity of each marketplace player (in other words, do you trust the identity of the person you are going to do business with, and is he/she reliable for doing business with financially ) and the policy (in other words, what business functionality is he/she entitled to). If this is the first time doing business with the trading partner, the Service Requester would often like the Service Provider or the Service Broker to authenticate the identity of the trading partner first. The Service Provider or the Service Broker will also authenticate the identity of every business corporation (trading partner) who publishes business services and service details in its Service Registry. This ensures that the trading partner is not someone with a fake identity or somebody who is masqueraded by a security hacker.

Figure 7-3 elaborates the security concerns for the same business scenario with details. Security threats may come from different areas to attack the identity and the policy (also refer to the following section on threat profiling). For instance, the identity of the Service Provider can be faked if the user id and password are being hijacked (identity). A man-in-the-middle security attack may modify the service request content (such as modifying the account number in a financial transaction), which affects the reliability of the message security, the data transport security, or the platform security. These security risks may be a result of an overlooked security design or any security implementation pitfalls.

Currently, the platform security (such as operating system security hardening), the data transport security (such as HTTPS), and the messaging security (such as WS-Security, XML Encryption/XML-ENC, and XML Signature/XML-DSIG) are security design elements that address the security concerns regarding the identity of the consumer or Service Provider. Once the identity is established and authenticated, the consumer or the Service Provider would be reliable to do business with.

The next security design element is the reliability of the business transaction between the consumer and the Service Provider. Liberty, together with the SAML specification, is a security specification to establish a Circle of Trust (cross-domain Single Sign-on) where consumers can sign on once to the B2B marketplace to do reliable business transactions. Within the B2B marketplace, trading partners can also use the messaging security and the data transport security to assure the reliability of the business transactions.

Another security design element is policy. XACML and WS-Policy are examples of security specifications that help govern only authorized users who can access the business transactions or resources. This would safeguard any unauthorized access to sensitive business information between different enterprises (or domains).

The following section discusses the concepts of identity, trust, policy, and threat profiling in the Web Services security framework. Identity denotes how to authenticate the valid identity of the Service Requester or user. This requires authentication of the user credentials (security tokens in the form of user id/password, digital certificates, or Kerberos tickets) and platform security.

Trust denotes how to secure the messaging and transactions between two entities (identities). If the two entities (Service Requester and Service Provider) are authentic, the Service Requester is authenticated with the Service Provider, and they are within a secure environment, then they are in a Trust Domain. Service Providers exchanging messages with Service Requesters from an unauthenticated source or over the public Internet are often considered within a Non-trust Domain. In both cases, Web Services applications require the use of different security mechanisms for the complete Web Services security stack (refer to previous section) in order to support transactional security. This would require a combination of platform security (for example, Operating System security hardening), data transport security (for example, HTTPS), and messaging security (for example, WS-Security) in order to support the requirements of confidentiality, traceability, non-repudiation, data integrity, and availability.

Policy denotes authorization (entitlement) for accessing different resources, policy enforcement, and policy decision.

Threat Profiling denotes profiling the Web Services objects, tools, and applications in order to assist in protecting these resources from potential hacker attacks and unauthorized access. This will involve defining and reinforcing security policies on how to protect and implement security mechanisms for the Web Services objects, tools, and applications on an ongoing basis.

The following structural framework in Table 7-2 covers the core components to establish a Trust Domain, which is suitable for your organization, and what threats and potential risks exist for each Trust Domain.

Table 7-2. Web Services Security Framework

	Security Technology or Standards	Security Requirements
Trust Domains
Key management	XKMS Host security hardening	Authentication Confidentiality Traceability Non-repudiation
Authentication	Single Sign-on with SAML and Directory Server	Authentication Entitlement Traceability Availability
Transactional security	XML Encryption, XML-DSIG XACML WS-Security Client and host security hardening	Entitlement Confidentiality Availability Data integrity Non-repudiation
Threat Profiling
Web Services objects	Security hardening for UDDI configuration files and WSDLs	Data integrity Availability
Hacker attack	Profiling of transaction loading/capacity to support availability and scalability Client and host security hardening Virus protection for hosts Intrusion detection testing Patch management for software platform (for example, buffer overflow)	Availability Confidentiality Traceability Authentication Entitlement Non-repudiation

Trust Domains

From a security perspective, a business service and data exchange is reliable only if both parties are "trusted," and are not "John Does" from an unknown place. Trusted parties here do not refer to business trust. The term trusted denotes the trust relationship between trading partners (if this is cross-enterprise) or business units (enterprise). A trusted trading partner means that he/she is authenticated with a valid network identity. His/her user credentials are issued and managed by an authorized Identity Provider. Under the management of the authentic Identity Provider, it is secure to exchange business documents between the "trusted" trading partners. Business-to-Business transactions often involve high monetary value transactions (for instance, a Purchase Order containing a monetary value of over $1 million U.S.), and thus authentic identity and a trust relationship are crucial to reliable business services.

This trust relationship may be implemented by a combination of technology and processes. Examples of the technology are Public Key Infrastructure (which involves key management for trading partners), authentication of credentials using Directory Server, use of XML-based encryption, and digital signatures for transaction security.

Different business models of the trust relationship between trading partners, or Trust Domains, may influence how these technologies are used. If a business corporation decides to use an external Certificate Authority to issue digital certificates and manage key issuance, this trust service is a managed trust domain. However, if the business corporation has a large IT organization and decides to manage its own trust service, including key management, authentication services, and digital certificate operational support, then this is a client-responsible Trust Domain. The business may also decide which trust model (hierarchical, distributed, or direct) is suitable to implement its Public Key Infrastructure. In either case, each trust domain has different Use Cases for key management, authentication of client and hosts, and handling of transaction security.

Key Management

Security tokens such as X.509v3 digital certificates are fundamental to generating digital signatures for transactions. They are also the key to authenticating user credentials and network identity. Transactions that are signed with digital signatures are confidential and cannot be repudiated.

XKMS provides a framework for implementing key management. There are a few implementations to support different trust domains. Under the client-responsible Trust Domain, if customers are managing their own PKI infrastructure, they would probably prefer deploying Certificate Management Server together with home-grown key management and call center operation processes (for example, Certification Practice Statement and Certificates Policies).

Under the managed Trust Domain, these security tokens or key pairs are issued and managed by an external trust service such as an external Certificate Authority (for example, UK Post Office or Identrus). Customers need to establish a Web Services call for key retrieval or validation of the key name against the public key.

In either scenario, the server hosting the PKI infrastructure (for example, Certificate Management Server) or the client requesting the XKMS requests needs to be securely hardened. Examples of platform security hardening tools are Titan (http://www.fish.com/titan/) and SATAN (http://www.fish.com/satan/). These tools scan and identify different network services and ports that are unused and may be easily exploited by hackers.

Authentication

Form-based (users presenting user id and password in an HTML form) or security token (such as X.509v3 digital certificate) authentication are common means to validate the network identity within an application. For enterprise-wide applications, authentication is usually implemented using security tokens and Directory Server. This requires all applications, including back-end legacy systems, to invoke authentication services (such as LDAP authentication APIs or SAML assertion requests) from the authentication server. Thus, enterprise-wide Single Sign-on is crucial to the user experience and security administration. The capability to sign on once with the partners' systems is also more complex, as the trading partners are unlikely to use the same authentication service or infrastructure.

Historically, Single Sign-on can be implemented by either proprietary authentication APIs on both ends, secure server-side cookies (such as Netegrity's Siteminder), meta-directory (such as Sun ONE Meta-Directory), or PKI implementation using digital certificates. Each of these options has drawbacks.

SAML is a security protocol designed to address Single Sign-on, within an enterprise or across enterprises. It assumes the trading partners do not share the same security infrastructure and authentication mechanism. Using SOAP calls, SAML does not require customers to change the existing security infrastructure. SAML requires the client requester (Relying Party), under either the client-responsible or the managed Trust Domain, to send a request for authentication assertion during login to the Issuing Authority, which returns a SAML Assertion Response.

SAML is dependent on a reliable key management infrastructure and processes, as discussed earlier in a previous section. It is now a core component of the Project Liberty specification.

Transaction Security

Message-level and application-level security provides protection for the transaction. An appropriate choice of encryption algorithm (such as XML encryption or XML-ENC) together with a digital signature (such as XML Signature or XML-DSIG) is essential for the transaction security. XACML attempts to provide a data-level access and addresses issues like sending different subsets of the XML data contents to different groups of users.

The WS-Security specification, dated April of 2002, attempts to define a broader Web Services security framework by consolidating variants of security token and encryption specifications. The interoperability aspects of how Single Sign-on and transaction security are implemented have not yet been articulated .

Different Web Services security specifications have provided a good framework. However, the reliability and scalability of the transaction security really depends on the physical implementation of the security infrastructure and the application design. The reliability and security of the client and host platform requires security hardening. Most hackers do not know these application security aspects, but they are able to hack into the transactions from the platform security loopholes.

Threat Profiling

Web Services Objects

The following objects may become targets of attacks. Understanding how these objects operate will help defend against attacks.

Hosts

Many servers running Windows 2000 or Solaris OE are installed with default configuration settings. This could be an issue of security threat. For example, default configuration settings in Windows operating systems leave most objects and resources unprotected (for instance, an anonymous id can access these objects). Most customers may not be aware of the need to download and install security patches to the operating system in a timely way. Thus, many unused ports or services, such as RPC or COM+ objects, can be easily exploited.

The example in Figure 7-4 shows a list of risky areas, identified by Titan and NMAP, on a Unix host (IP address 10.4.16.14) running Apache Tomcat and SOAP using the default installation. Please note the interesting ports that may be open to security attacks or exploits.

UDDI Host Scan

Figure 7-4 is a scan log of the Unix host drip9 (IP address is 10.4.16.19) generated by NMAP. The interesting ports are RPC (which is different from XML-RPC), which are easily exploited.

Figure 7-4 UDDI Host Scan

 %./nmap -v -sU -sT drip9 Starting nmap V. 2.54BETA34 (www.insecure.org/nmap/) Host drip9 (10.4.16.19) appears to be up ... good. Initiating Connect() Scan against drip9 (10.4.16.19) Adding open port 8080/tcp Adding open port 8081/tcp ... The Connect() Scan took 1 second to scan 1556 ports. Initiating UDP Scan against drip9 (10.4.16.19) Too many drops ... increasing send delay to 50000 The UDP Scan took 357 seconds to scan 1459 ports. ... Adding open port 32771/udp  Interesting ports on drip9 (10.4.16.19):  (The 2973 ports scanned but not shown below are in state: closed) Port       State       Service ... 21/tcp     open        ftp 22/tcp     open        ssh 23/tcp     open        telnet ... 42/udp     open        nameserver 79/tcp     open        finger  111/tcp    open        sunrpc   111/udp    open        sunrpc  161/udp    open        snmp 512/tcp    open        exec 513/tcp    open        login 514/tcp    open        shell 514/udp    open        syslog 517/udp    open        talk 540/tcp    open        uucp 587/tcp    open        submission 2049/tcp   open        nfs 2049/udp   open        nfs 4045/tcp   open        lockd ... 8080/tcp   open        http-proxy 8081/tcp   open  blackice-icecap  32771/tcp  open  sometimes-rpc5  32771/udp  open  sometimes-rpc6  32772/tcp  open  sometimes-rpc7  32773/udp  open  sometimes-rpc10  32779/tcp  open  sometimes-rpc21  Nmap run completed  1 IP address (1 host up) scanned in 360 seconds # 

Apache Tomcat/UDDI Host Security Healthcheck

Figure 7-5 is extracted from a detailed report generated by Titan. Titan also explains the potential risk areas (in this example, they refer to the unused Unix services and IP ports) and makes recommendations to mitigate the risks. These risks, such as login and shell defaults, are common to platform security and thus also applicable to a Web Services implementation. Nevertheless, Titan's findings varied when scanning a Unix host with and without Apache Tomcat, Apache SOAP, and Apache Xindice database (for storing UDDI objects) respectively.

In this excerpt, RPC and IP forwarding are two common risks for Web Services implementation, which may be open to security attack or exploit using buffer overflow.

Figure 7-5 Titan's Scanning Result of a UDDI Host

[View full width]

 __________________________________________________ *=*=*=*=* Running modules/disable-L1-A.sh now..... Output to ../logs/modules/disable-L1-A.sh.V.113340 =========================== Abort sequence set to enable - FAILS CHECK Titan Recommendation: (disable-L1-A.sh -f) This is a physical access issue. If a person  can abort the current Solaris session, and reboot using an alternate device, (see eeprom  .sh -f) they can access/modify any file. Titan sets abort sequence to: KEYBOARD_ABORT=disable in /etc/default/kbd ============================================================== bin shell = - FAILS CHECK Titan Recommendation: (disable-accounts.sh -f) Set system accounts defined as: any accounts less than UID 100 or greater than UID 60000 to /bin/true or to another  non-interactive shell. This keeps bad guy from putting in a /usr/bin/.rhosts on a NFS  exported partition and being able to rsh/rlogin as user bin. It is recommended that the Titan binary for noshell be compiled and used as it notifies  the administrator of access attempts to a reserved system account. (see /tmp/Titan,v4.0BETA2/arch/sol8sun4/bin/src1/noshell.c) ============================================================== Service S88sendmail still active in /etc/rc2.d - FAILS CHECK Titan Recommendation: (disable-services.sh -f) Disable NFS server, NFS client, and *RPC on  all systems that don't require them. Note - RPC is required on HA systems. Use Ipfilter or EFS Lite to restrict RPC on these  networks. ============================================================== Service S71rpc still active in /etc/rc2.d - FAILS CHECK  Titan Recommendation: (disable-services.sh -f) Disable NFS server, NFS client, and *RPC on  all systems that don't require them.   Note - RPC is required on HA systems. Use Ipfilter or EFS Lite to restrict RPC on these  networks. Service S76snmpdx still active in /etc/rc3.d - FAILS CHECK  _____________________________________________________ *=*=*=*=* Running modules/disable_ip_holes.sh now..... Output to ../logs/modules/disable_ip_holes.sh.V.113340 =========================== Checking kernel settings using ndd IP source routing is currently set to 1 System allows source routed packet forwarding - FAILS CHECK  Titan Recommendation: (disable_ip_holes.sh -f) Disable ip_src_routed, broadcast, and use  strict multihoming. Add to /etc/rc2.d/S69inet:  ndd -set /dev/ip ip_forward_src_routed 0 ndd -set /dev/ip ip_forwarding 0 ndd -set /dev/ip ip_forward_directed_broadcasts 0 ndd -set /dev/ip ip_ignore_redirect 1 ndd -set /dev/ip ip_strict_dst_multihoming 1 _____________________________________________________ *=*=*=*=* Running modules/fix-cronpath.sh now..... Output to ../logs/modules/fix-cronpath.sh.V.113340 ===========================  File /var/spool/cron/crontabs/root exists; continuing ...          No cron.allow file - FAILS CHECK          No at.allow file - FAILS CHECK 

UDDI Service Registry

Local configuration or data files for the UDDI Service Registry are potential targets for attack. For example, Apache Xindice, which Java Web Services Developer Pack uses to store the UDDI Service Registry objects, stores data contents under $JWSDP/tools/db/uddi and system access information under $JWSDP/tools/db/system. WSDL files, if they are stored in the Service Registry, are critical files that hackers may locate using the service end-point URL as targets of attack.

Web Container/Application Server

Some Web Containers or Application Servers store user access files in clear text (for example, Apache Tomcat stores users and passwords in $CATALINA/conf/ tomcat-users ). Saumil Shah and Shreeraj Shah, in RSA Conference 2002 (refer to http://www.rsaconference.net/RSApresentations/ pdfs /devthu1015_shah.pdf for details) identify another area of threat from specific application server implementations, where hackers may exploit the abuse of URL to CLASSPATH mapping, or cause source code disclosure or arbitrary file retrieval by forcing a FileServlet on a JSP file. In most cases, the application server may have a security patch already. They suggest some countermeasures, such as avoiding the use of servlet invocation by URL to CLASSPATH mapping as much as possible, disallowing any meta- characters (for example, * or .) as part of the URL, unregistering any unused alias mappings, and isolating the system's core servlets from application servlets.

Hacker Attacks

Typical hacker attacks usually start with information gathering by footprinting, scanning, and enumeration. If Web Services applications are implemented with poor security, hackers may simply intrude into the system and access data contents. For security-hardened systems, hackers may attempt Denial of Service or middleman attack.

Denis Piliptchouk and Vince Dovydaitis, in RSA Conference 2002 (refer to http://www.rsaconference.net/RSApresentations/pdfs/devwed1115_piliptchouk.pdf for details), compared the security features of .NET with those of Java. Interestingly, they note that both languages have similar capabilities with cryptography, authentication, and authorization services. The key difference is that .NET security design is to enable all features by default, while Java is to disable all features by default. Both .NET CLR and Java provide a sandbox for program execution and store configurations in XML files. Therefore, it is the overall design quality that impacts the security of a Web Services implementation.

Denial of Service

A common approach to attacking Web Services applications with implementation of key management and digital signatures is a Denial of Service (DoS) attack. This is based on some information gathering about the profiling of the loading and capacity from the service end-point URLs in the WSDL files. One possible countermeasure is to review the "ilities" of the overall architecture and to profile the loading and capacity regularly as preventive measures.

Man-in-the-Middle Attack

A likely security attack approach, illustrated in the scenario in Figure 7-6, is to spoof service requests to Web Services end-points by reusing previous key information and key name, which are captured from previous footprinting. In this example, a SOAP client is sending a SOAP message that contains a fund transfer request in clear text. The data content includes user id and password. The SOAP message is in unencrypted clear text and is supposed to be signed with a digital signature. It is assumed that SOAP messaging does not need data encryption within an internal proprietary network. Unfortunately, hackers acquire a WSDL document in advance and sniff for a copy of SOAP messages from the internal network. Then, they may modify the SOAP message contents and post it to the target service end-point URL.

Figure 7-6. Man-in-the-Middle Attack Risk for Web Services Applications