Web Services is one of the primary method of implementing SOA in highly distributed enterprise computing environments where not only the enterprise applications need to be integrated with internal applications, but also with the external systems built and operated by various business partners. That requires such services exposed beyond the trust boundaries of the enterprise and thus increasing the security threat landscape.
Securing webservices is more complicated than any other end user systems, as the webservices are built as the conduit between systems rather than human users. Most of us are very familiar with the first line of defense, namely authentication, data integrity, confidentiality and non repudiation. These are certainly critical security concerns, but there are well established tools and practices that help address these security issues. But, this it not just be enough to be contempt with solving these concerns, as the services are no longer constrained within the trust boundaries.
While other types of applications have executables that act as an outer layer and protects the application's internals, webservices don't have such outer layer and thus expose the internals to potential unforgiving hackers on the internet or intranet. Testing and securing webservices require a toolkit with abilities to act like a client or for that matter its proxy and being able to intercept, transform or manipulate the messages that are being exchanged. Having said that, the toolkits alone would not guarantee a complete solution to combat the security exposure of the webservices. There need to be an understanding of the application, context, trust boundaries etc, which will help to enumerate the potential threats that need to be managed and then use the toolkits.
In this blog, let us have a look at the potential threat categories beyond the first line of defense that an organization should be aware of and be prepared to combat. As always, the attempt is to come up with the most significant threats and not to produce an exhaustive list of such threats. Determination of the specific threats under each category requires an analysis of the application and its internals in line with the trust levels.
Privilege Escalation
Virtually all attacks attempt to do something the attacker is not privileged to do. The hacker wants to somehow leverage whatever limited privilege he has, and turn it into higher ("elevated") privilege, as a result of potentially flawed authentication and authorization mechanisms. Sometimes, hackers would exploit vulnerabilities in the internal components of the service, be it custom coded or third party components and thus gaining privileges for remote code execution or database manipulation. It is obvious that the consequences of such breach could be severe leading to financial and non financial damages.
While the protection for such vulnerabilities depends on the specifics of the application and its architecture, as a general best practice, the authentication and authorization needs of each of the internal components shall be carefully established based on the least privilege principle, by considering additional contextual information like the client, location, or network in addition to the basic credentials and by implementing multiple levels of authentication within the service components can alleviate this category of threats. When third party components or run times are used, it is important to constantly apply the security patches that the vendors may release.
Denial of Service
The interoperable and loosely-coupled web services architecture, while beneficial, can be resource-intensive, and is thus susceptible to denial of service (DoS) attacks in which an attacker can use a relatively insignificant amount of resources to exhaust the computational resources of a web service. Denial of Service attack is aimed at causing impact on the availability of the underlying network, compute or storage resources for the legitimate service consumers. Given that webservices are typically used in high availability enterprise integration scenarios, even a smaller magnitude of DoS attach could cause sever disruption in all the connected systems and leading to breach of SLAs with partners and thus at times leading to financial damage as well.
The effects of these attacks can vary from causing high CPU usage, to causing the JVM to run out of memory. Clearly the latter is a critical vulnerability. Protection for DoS can be implemented at different levels with a view to ensure legitimate of use of the underlying resources. Some of the techniques used to combat DoS attacks are to implement various algorithms to restrict access to critical internal components to legitimate requests and rejecting the rest. For instance, the input message size limits can be validated in line with the speciific service method and if the requests carry an unusually large xml messages than expected, such requests can be rejected at the network layer itself. Tools and appliances are available to combat the DoS attacks, but how such tools and appliances are setup and configured would depend on the specific needs.
Spoofing
Spoofing attacks are successful when one entity in a transaction trusts another entity. If an attacker knows about the trust, they can exploit it by masquerading as the trusted party. This can also be masquerading the additional contextual information which is used in authentication or in request processing. The most common of such information are SOAPAction and client IP. There are various ways to exploit credentials or spoof the source of messages. These include credential forgery, session hijacking and impersonation attacks. The services shall be designed to appropriately validate such information in isolation and in combination with other related information, so as to establish the request is legitimate.
Repudiation
An important web services security requirement is nonrepudiation. This requirement prevents a party from denying it sent or received a message. The way to implement this is using Xml Digital Signatures. For example, if I sent a message which is signed with my private key, I cannot later deny that I sent it. This concern arise when the web service does not bind the client to their actions using appropriate techniques or due to flawed implementation of auditing and logging requirements. Data inconsistency is one of the common outcome of this threat and could lead to sever damages to the enterprise.
A combination of the protection measures against various threat categories would help combat this threat. For instance, an adequate protection from spoofing, protecting the messages while in transit coupled with appropriate logging and audit implementations would help minimize the risks arising out of this threat.
Information Privacy
As web services are typically implemented as part of a complex system and have access to a large amount of potentially sensitive information, it is important to ensure that access to the information is restricted. The transfer of the data should also be secured to prevent eavesdropping and sniffing threats. Privacy or confidentiality concerns with webservices is no different than that in any other system. As such, the information disseminated through the information has to be reviewed in line with the organization's information sensitivity policy and apply policies and rules to ensure that when to allow a specific request have access to such information. This will involve not only appropriately defining the authorization rules for the clients and users, but also carefully considering the information or parameters that are received as part of the request message
Message Tampering
Webservice messages, both request and responses if not appropriately protected can be tampered using various attack methods. Web services being a component of a complex distributed enterprise system with integration with multiple partner systems throws open the possibility of message tampering as it is exposed beyond the boundaries with multiple communication paths. Attacks under this threat category include man-in-the-middle attacks and implanting trojans and malwares. As with the other threats, this can also cause severe damages. Compromise under this category may also mean a compromise in one or more other threat categories. For instance, a tampered input message might lead to spoofing of identity and thus compromising the information privacy, etc.
To conclude, as the protection measures are evolving on the one side, newer threats are also emerging and the security professionals need to have a continuous engagement, and have an appropriate security or threat management framework implemented to combat the existing and emerging threats. Periodical security audits shall be supplemented with a formal security testing with necessary toolkits in place. All said and done, the extent of protection should depend on the organization's risk policies and risk appetite, the critical nature of the webservices and the trust boundaries.
Securing webservices is more complicated than any other end user systems, as the webservices are built as the conduit between systems rather than human users. Most of us are very familiar with the first line of defense, namely authentication, data integrity, confidentiality and non repudiation. These are certainly critical security concerns, but there are well established tools and practices that help address these security issues. But, this it not just be enough to be contempt with solving these concerns, as the services are no longer constrained within the trust boundaries.
While other types of applications have executables that act as an outer layer and protects the application's internals, webservices don't have such outer layer and thus expose the internals to potential unforgiving hackers on the internet or intranet. Testing and securing webservices require a toolkit with abilities to act like a client or for that matter its proxy and being able to intercept, transform or manipulate the messages that are being exchanged. Having said that, the toolkits alone would not guarantee a complete solution to combat the security exposure of the webservices. There need to be an understanding of the application, context, trust boundaries etc, which will help to enumerate the potential threats that need to be managed and then use the toolkits.
In this blog, let us have a look at the potential threat categories beyond the first line of defense that an organization should be aware of and be prepared to combat. As always, the attempt is to come up with the most significant threats and not to produce an exhaustive list of such threats. Determination of the specific threats under each category requires an analysis of the application and its internals in line with the trust levels.
Privilege Escalation
Virtually all attacks attempt to do something the attacker is not privileged to do. The hacker wants to somehow leverage whatever limited privilege he has, and turn it into higher ("elevated") privilege, as a result of potentially flawed authentication and authorization mechanisms. Sometimes, hackers would exploit vulnerabilities in the internal components of the service, be it custom coded or third party components and thus gaining privileges for remote code execution or database manipulation. It is obvious that the consequences of such breach could be severe leading to financial and non financial damages.
While the protection for such vulnerabilities depends on the specifics of the application and its architecture, as a general best practice, the authentication and authorization needs of each of the internal components shall be carefully established based on the least privilege principle, by considering additional contextual information like the client, location, or network in addition to the basic credentials and by implementing multiple levels of authentication within the service components can alleviate this category of threats. When third party components or run times are used, it is important to constantly apply the security patches that the vendors may release.
Denial of Service
The interoperable and loosely-coupled web services architecture, while beneficial, can be resource-intensive, and is thus susceptible to denial of service (DoS) attacks in which an attacker can use a relatively insignificant amount of resources to exhaust the computational resources of a web service. Denial of Service attack is aimed at causing impact on the availability of the underlying network, compute or storage resources for the legitimate service consumers. Given that webservices are typically used in high availability enterprise integration scenarios, even a smaller magnitude of DoS attach could cause sever disruption in all the connected systems and leading to breach of SLAs with partners and thus at times leading to financial damage as well.
The effects of these attacks can vary from causing high CPU usage, to causing the JVM to run out of memory. Clearly the latter is a critical vulnerability. Protection for DoS can be implemented at different levels with a view to ensure legitimate of use of the underlying resources. Some of the techniques used to combat DoS attacks are to implement various algorithms to restrict access to critical internal components to legitimate requests and rejecting the rest. For instance, the input message size limits can be validated in line with the speciific service method and if the requests carry an unusually large xml messages than expected, such requests can be rejected at the network layer itself. Tools and appliances are available to combat the DoS attacks, but how such tools and appliances are setup and configured would depend on the specific needs.
Spoofing
Spoofing attacks are successful when one entity in a transaction trusts another entity. If an attacker knows about the trust, they can exploit it by masquerading as the trusted party. This can also be masquerading the additional contextual information which is used in authentication or in request processing. The most common of such information are SOAPAction and client IP. There are various ways to exploit credentials or spoof the source of messages. These include credential forgery, session hijacking and impersonation attacks. The services shall be designed to appropriately validate such information in isolation and in combination with other related information, so as to establish the request is legitimate.
Repudiation
An important web services security requirement is nonrepudiation. This requirement prevents a party from denying it sent or received a message. The way to implement this is using Xml Digital Signatures. For example, if I sent a message which is signed with my private key, I cannot later deny that I sent it. This concern arise when the web service does not bind the client to their actions using appropriate techniques or due to flawed implementation of auditing and logging requirements. Data inconsistency is one of the common outcome of this threat and could lead to sever damages to the enterprise.
A combination of the protection measures against various threat categories would help combat this threat. For instance, an adequate protection from spoofing, protecting the messages while in transit coupled with appropriate logging and audit implementations would help minimize the risks arising out of this threat.
Information Privacy
As web services are typically implemented as part of a complex system and have access to a large amount of potentially sensitive information, it is important to ensure that access to the information is restricted. The transfer of the data should also be secured to prevent eavesdropping and sniffing threats. Privacy or confidentiality concerns with webservices is no different than that in any other system. As such, the information disseminated through the information has to be reviewed in line with the organization's information sensitivity policy and apply policies and rules to ensure that when to allow a specific request have access to such information. This will involve not only appropriately defining the authorization rules for the clients and users, but also carefully considering the information or parameters that are received as part of the request message
Message Tampering
Webservice messages, both request and responses if not appropriately protected can be tampered using various attack methods. Web services being a component of a complex distributed enterprise system with integration with multiple partner systems throws open the possibility of message tampering as it is exposed beyond the boundaries with multiple communication paths. Attacks under this threat category include man-in-the-middle attacks and implanting trojans and malwares. As with the other threats, this can also cause severe damages. Compromise under this category may also mean a compromise in one or more other threat categories. For instance, a tampered input message might lead to spoofing of identity and thus compromising the information privacy, etc.
To conclude, as the protection measures are evolving on the one side, newer threats are also emerging and the security professionals need to have a continuous engagement, and have an appropriate security or threat management framework implemented to combat the existing and emerging threats. Periodical security audits shall be supplemented with a formal security testing with necessary toolkits in place. All said and done, the extent of protection should depend on the organization's risk policies and risk appetite, the critical nature of the webservices and the trust boundaries.
