Using Web Services in a Secure Environment
Introduction
Web services have arisen as a straightforward way of allowing
multiple systems to communicate and interact with each other. They enable data to easily flow through many
computers across numerous networks.
However, by their very nature, web services open themselves up to
security issues as do exchanges of any data.
If the data being exchanged via web services is sensitive, you need to
ensure that the information is kept confidential and that the integrity of the
message remains intact. Confidentiality,
integrity, and authenticity are the main areas of concern when dealing with web
service security.
·
Confidentiality
means that only authorized users are able to view the data in its original
form. The simplest case is when someone sends
a web service request or receives a response, only the sender and the recipient
should be able to view the actual contents of the message. This does not mean that the data is
completely hidden from prying eyes. This is impossible since the data needs to
be transmitted through multiple systems before reaching its destination. Transmissions that maintain confidentiality
ensure that anyone who intercepts the message (who is not the intended
recipient) will be unable to view the same data that the sender or recipient
would see. The most common means of
ensuring confidentiality is by having the sender encrypt the data before
transmission while the recipient decrypts the data to view the original
content.
· Integrity means that the data has not been altered during transit and that it is identical to the data transmitted. The most common means of ensuring integrity is by digitally signing the data. Once the data is digitally signed, any changes to the data will cause it to be corrupted.
· Authenticity provides the recipient of the web service request with the ability to confirm or deny that the data comes from the appropriate sender, that the sender is trusted, and that the sender has the appropriate permissions to transmit the data. Signatures, user names, and passwords can be used to confirm the identity of a sender.
These three areas form the backbone of a secure web service environment. If a web service cannot guarantee with some level of confidence that all three of these areas have been addressed, the web service is not as secure as it could be.
This paper describes a case study where web services were successfully used to handle highly sensitive data and also discusses the various levels of security possible when using web services.
Case Study
The problem in this case was to transmit secure information about a customer from one computer to another. The target computer published a web service that needed to be called by the source computer. The source computer would extract all of the customer information and store it in an XML data file. This same information was shown to the customer on screen using a form representation product originally built by the company PureEdge (recently acquired by IBM). Using a signature pad, users would sign the document. The signature portion of the document is extracted to a PDF. When the web service is called, both the XML data file and the PDF signature page were passed to the web service.
The information being transmitted in this case needed to be highly secure and fell under the jurisdiction of the Privacy Act of 1974. Therefore, the penalty for this information being visible or accessed by unauthorized users was severe. In addition, the information consisted of legal documents. Thus, it was vitally important that the information could not be intercepted or fraudulently manipulated.
In order to achieve the security objectives for this project, a number of measures were taken:
1. Even though the front-end application being used had hundreds of users worldwide, all calls to the web service were made by a single source application server.
2. In the source environment, traffic is typically routed through a proxy server, which would effectively grant anyone with access to that proxy server the ability to call that web service. To prevent this, specific permission was granted to the source application server to bypass the proxy server and directly call the web service. Therefore, the web service in this case can only be called by specifically named IP addresses.
3. Both the source and target servers only existed within the .mil domains and were therefore invisible to normal Internet traffic.
4. A specified path routed through several firewall devices was set up between the source and target servers. Each firewall device required setting up permissions to allow the request to come from a specific application server IP address.
5. In order to prevent interception, manipulation, or retransmission of web service calls, the clock times on the source and target computers had to be synchronized so that if a web service call arrives with an out of date timestamp, it is automatically rejected.
6. The authors of the web service in the target environment created an encryption program to encrypt the data prior to being passed to the web service. An executable version of this software was passed to the source computer development team but the source code was not distributed. Therefore, the method of encryption was not even known to the source development team.
7. Standard user name/password authentication was used by the web service.
8. Standard HTTPS secure socket transmission was used for the web service.
9. Digital signatures were installed on the source computer in order to further authenticate the web service call.
There were some initial difficulties in getting the system set up as well as some ongoing challenges. The most difficult part of setting up was establishing the initial connectivity between the source and target computers. Routing through several firewalls, all of which required valid declaration of the source IP address for successful transmission, was particularly difficult. Determining the appropriate firewalls, identifying the right resource with knowledge about opening the firewall, and getting permission to open the firewall were time consuming tasks that required several weeks to complete.
On the source side, getting permission to bypass the proxy server, although not a significant technical challenge, turned out to be a significant political challenge. In general, the political challenges of working in a secure environment are often much more difficult to overcome than the technical ones.
After the system had been running for several months, it was necessary to make some hardware changes. Having gone through the process of setting up the system initially, it was somewhat easier to make the necessary modifications. Getting permission for new digital certificates still required some significant time expenditure.
The most important lesson learned was to budget several weeks of time to establish connectivity between the source and target computers in order to handle all communications securely.
One area that continues to be a challenge is the time synchronization between the source and target computers. In large computing facilities, this function is usually centrally managed. There are two different time managers for the source and target systems. Periodically one of the systems ends up being off by several minutes which then invalidates all of the web service calls.
Setting
up and maintaining the secure environment was a significant but not
particularly technically difficult challenge.
The most important part of the process was the security review to make
sure that the architecture we had devised was indeed secure.
Web Service Security Levels
This section describes the various levels of security that can be placed on web services and how they can be used to ensure that the data transmitted will not be intercepted or manipulated.
Transport-Level Security
Security measures can be placed at different levels, depending upon
a host of factors such as the system architecture, business needs, and the capabilities
of the client system. One of the more
well known areas to place security is on the transport level. Transport-level security deals with securing
the actual means of transmitting the information. This level is known to most developers since,
in addition to its use with web services, it is also used for most secure
Internet traffic.
Secure Socket Layer (SSL)
Encrypting data using HTTPS
is commonly used to handle Internet-based security and is probably sufficient
enough for most business needs. However,
there are some circumstances where this approach is not adequate and should not
be used as the only means to secure web services. While HTTPS provides adequate security
between two end points, it only provides security between the endpoints, making the data vulnerable at the
endpoints. This becomes a problem under
certain architectures where a single transmission needs to be processed by intermediary
servers. A shown in Figure 1, the web service request
actually goes to a “relay” server before being transmitted to the real web
service system. Using this path, the
data is not secure while it is being processed on either server, leaving it open
to possible “eavesdropping.” If both of
the servers are trusted and should have access to the entirety of the message,
then this should not pose a security threat. However, if one or more servers
this chain is not trusted, or is only trusted with certain parts of the message
then this security measure is not enough.
A similar situation exists if the client is using a proxy/firewall that
does not allow tunneling. In this case, the proxy/firewall acts in the same
manner as the intermediary server, exposing the data to the proxy/firewall
server.
Figure 1: Intermediary server configuration
Due to the interoperability of web services, it has become more commonplace for a web service to receive a request, use some of the information for its own purposes, and pass the rest to one or more servers. Using the example of a business web service hosted by the Human Resources (HR) department used to add new employees to the system, the information sent to the web service would most likely contain basic but confidential information about the employee which would be stored in the HR system. The HR system may then need to pass along other parts of the request (such as the department to which the employee will be assigned) to web services in other departments. In this case, it may be desirable for some information to be available to the HR system but not to the specific department and vice versa.
If the two endpoints for the web service communication are always
the client and the web server without any intermediary servers (such as proxy
or relay) in between, then HTTPS is probably an excellent means to protect the
confidentiality of the data in the call.
If intermediary servers do exist, then HTTPS is probably still a valid
means to protect the contents of the message in transit. Extra layers of
security can be added to ensure that the communication remains secure at all
points.
Firewalls
Another transport-level security measure that is fairly easy to
implement is using a firewall to limit traffic to the web service. If the web service is a specialized system
that a small group of predefined users are able to access, then one of the
strongest forms of protection to limit web service exposure is to block all
traffic to the server except that which originates from IP addresses of known users of the web
service. This measure ensures that only
authorized users will be able to access the system and also limits the exposure
of the server itself to Internet-based attacks such as denial of service (DOS).
While very effective in limiting inbound traffic, this approach is
not always feasible since it requires that all traffic on a specific port
(usually HTTPS port 443) needs to be filtered to only allow certain users to
gain access. If the server in question
is a dedicated system only used for this web service, this should not pose much
of a problem. However, if the other
server also acts as a normal web server by filtering IP traffic, the result
would be to limit people from connecting to the web server as well as the website,
which may not be desirable. Another possible
problem occurs if one or more authorized users access the web service through a
proxy/firewall on their side so that the server request appears to originate
from the proxy server and that IP address needs to be added to the list valid
IP addresses. By opening the firewall to
allow traffic originating from a proxy server, it allows anyone who has access
through that proxy to access the web service.
Depending on the business needs, this may expose the web service to a
much larger user group than intended or desirable.
Message-Level Security
Beyond the transport level security measures discussed above which
are common to most forms of secure Internet traffic, web services offer greater
flexibility for encrypting, authenticating, and signing messages. The Simple Object Access Protocol (SOAP) used
in web service communication allows for encrypting and signing of different
blocks of the message as well as the ability to add tokens identify the
sender. This combination of features
allows web service messages to fulfill security requirements for a host of
environments and situations.
Encryption
As previously discussed, calling a web service via HTTPS encrypts the entire message during transit but has some unwanted side effects when dealing with intermediary servers. One of the ways to overcome this security issue is to use encryption for individual elements of the web service message itself. Therefore when an intermediary server receives the message, the sensitive data in that message is still encrypted by other means. The current SOAP protocol allows individual XML blocks in the SOAP message to be encrypted using different keys. This flexible specification allows messages to be processed by multiple servers, with each server capable of accessing only the information that is intended for it. The rest of the encrypted data will be unreadable. There are two different types of encryption/decryption architectures available: symmetric and asymmetric key encryption.
Symmetric Key Encryption
Symmetric or single-key encryption utilizes a single key which all parties wishing to communicate securely must possess. The key is used as part of a mathematical formula to convert data or plain text into a seemingly random series of characters called ciphertext. The same key is then used in another mathematical formula to decrypt ciphertext and convert it back into plain text. With symmetric encryption, the single key is secret and must be held and protected by both parties. If either party’s key is compromised, unauthorized users will be able to both read the data and create fake transmissions.
Asymmetric (Public) Key Encryption
Asymmetric or public key encryption uses a similar methodology but different types of keys for encrypting and decrypting. With public key encryption there are two different, but related, keys public and private. The private key is held by the party who receives data while the public key is freely given to anyone wishing to send encrypted data to the private key holder. The system works using mathematical formulas which ensures that data encrypted using the public key can only be decrypted by the system holding the private key. For this very reason the keys have received their names. Since the private key can unlock the data, it must be kept secret. Anyone acquiring the private key they could intercept and read anything encrypted using the public key. Since the public key is typically only used for encryption, anyone can have access to the key and use it to encrypt data; however only the private key owner will be able to decrypt the data. The private key can also be used to encrypt data, but anyone with the public key from the pair would be able to decrypt the data so this is not a good security strategy.
Public key encryption can be utilized for web service security to
target certain pieces of data to different servers. If a web service call had to go through
several systems each requiring a different set of information, each piece of
data could be encrypted with the corresponding public key for the server that
piece was bound for. Since only the
corresponding private key would be able to decrypt the data, each piece of data
would remain confidential, except to the intended server. This type of encryption is valid if anonymous
users need to call the web service since only the public, freely available keys
are required.
Single key (symmetric) encryption requires that both parties have access to the same shared key. Use of this encryption method requires that the potential users be known ahead of time and logistics coordinated to provide appropriate parties with the shared key. Since shared keys increase the likelihood of being compromised due to the increase in the number of parties with access, they should only be used alone if all parties involved are adequately trusted and their environments are secure.
Both symmetric and asymmetric encryption methods can be combined by having the client create a random symmetric key, enclosing it as an element in the web service message, and then encrypting the symmetric key using the web services public key. The web service can decrypt the message, retrieve the symmetric key and use it to encrypt data and send it back. When the transmission is completed, the key can be discarded. Since the life of the shared key in this case is short, the security risk is significantly reduced. This approach also allows the message response to be encrypted so that only the sender will be able to read it.
Signatures
While encryption ensures that the data in the web service call
and response is unreadable to unauthorized users, it does not guarantee that
data has not been altered in some way. Even
encrypted data can be altered; however this typically results in the decrypted
data being completely corrupted and unreadable.
Likewise, you may wish to transmit unencrypted data, which should also
be unalterable. In order to ensure the
integrity of transmitted data, digital signatures can be utilized. Digital signatures allow data to be signed in
such a way that any consumer of the data can verify that the data has not been
changed since it was signed. Signatures
work similarly to public key encryption.
With digital signatures there is a private key and a public key. The private key is used to sign a block of
data. The signing process does not alter the data; instead it adds an
additional block of information that is used in the verification process. The public key is used in conjunction with the
verification block and the data to mathematically determine whether the data
has been modified or is the same as when the data was signed. The web service can utilize this technique to
verify that no signed data has been changed during transit and reject any
requests that have been modified.
Digital signatures also offer the added benefit of authenticating users. Since only the owner of the digital signature holds the private key, they should be the only one capable of producing a signature that can be verified using the public key. If the web service is set up to only allow specific digital signatures, then they can be used to verify the authenticity of the request. As long as the data can be verified as unaltered and the certificate can be verified as coming from an authorized user, you can ensure the authenticity of the request with a fair amount of accuracy. Likewise, the web service response can also be signed to verify to the caller that the response has not been altered and that it originated from web service.
Signatures are an excellent method of establishing the authenticity of users and the integrity of messages. Although signatures provide some of the best levels of security, you may not be able to utilize them in all system architectures. For instance, each user of the web service must have a digital certificate and the means to add a signature. Also the web service must know in advance which digital certificates it can trust.
Tokens
A less intrusive and somewhat less secure means of verifying the authenticity of web service users is to require that security tokens be placed within the message by the sender. The SOAP protocol allows for security tokens, allowing senders to specify a simple username and password to include with their message. The web service may then compare these tokens against a set of trusted tokens to authenticate and authorize user requests. You can also attach binary and XML tokens to the message in addition to simple username and password fields. When using security tokens, additional means should be used to ensure that the integrity of the tokens remains intact. This is usually accomplished by signing the tokens.
Timestamps
Another appropriate security measure that should be taken is to require that web service calls include a timestamp. Timestamps may not seem like a worthwhile security measure but their use can limit exposure to variety of different attacks. Timestamps allow the recipient to determine the freshness of the request. If some predefined amount of time has passed between the creation of the web service call and its receipt, it may be possible that something malicious has occurred. It is possible to intercept an expected web service call such as a bank calling a web service to deposit money into an account. Even if the exact contents of the message could not be deduced, the call could be replicated by intercepting the encrypted message. The message could then be retransmitted over and over to continually add money to the account. However, if the original message contained a timestamp, the next time that the message was transmitted it would most likely be expired and rejected. The web service could also log the timestamp of each request to prevent any requests with the same timestamp for a particular user. Although timestamps are useful, they have the additional overhead of requiring both sender and receiver to synchronize clocks in order to limit incorrect rejections. This hindrance has been lessened in recent years as more and more systems automatically synchronize their clocks to centralized servers.
System-Level Security
When used together, all of the security measures mentioned above offer a great deal of safety when working with sensitive data in web services. However, these measures can be easily compromised if the systems involved are not also secure. The toughest encryption or signature can be easily cracked if the perpetrator already has the private or shared key, or has access to the server housing the data. Both the web service servers themselves and the clients of the web service should be kept secure from both physical and remote intrusion. Even public keys should be handled carefully and securely. If a web service client is using a specific public key to encrypt messages, ensure that the public key is provided to the client in a secure manner. If the public key is intercepted and swapped, this renders the encryption useless except to provide a means of decrypting the message. Any code provided to clients for calling the web service should be digitally signed to make sure that no malicious code has been added.
Conclusions
Web service security is a complex multi-faceted issue that combines standard Internet security issues along with the extended security model for web services themselves. In order to ensure web service security, keep the following in mind:
1. Confidentiality
· Transmit over HTTPS
· Encrypt message parts
2. Integrity
· Sign message elements
3. Authenticity
· Filter firewall traffic
· Sign message elements
· Require security tokens (username/password, etc.)
· Timestamp messages
Project managers should not take for granted the difficulties associated with setting up secure services. The politics of security are often more difficult than the technical challenges of security. Developers should allow weeks of time to adequately support a secure environment.
About the Authors
Dr.
John Rydzy is a
Software Developer at Dulcian, Inc. He is responsible for development of
Java based user interfaces and client/server system communication. He has
recently graduated with highest distinction from