Presentation Layer: The presentation layer provides meaning to Web Services in many different ways. This meaning can be portrayed to an APPLICATION as an XML message/document. It can be presented to a human being in the form of a rich internet application (AJAX, Portal) or though many other presentation technologies available. The bottom line is that Web Services are designed for machine to machine communication but human interfaces are being used and as such you must understand these ramifications. Security Layer: Web Services Security is an important part of the web services stack although web service security is only a single component of enabling adequate web services security. Essentially WS Security provides security to information portrayed within the XML data structure Discovery: UDDI is a currently accepted method to publish and find web services. WSDL contains information about web services (Location, Description) and is commonly referred to within a UDDI. Access Layer: Common structure for accessing web services. (Described within WSDL, and universally accepted) Transport Layer: Common web transports relied on by web services (HTTP/HTTPS and JMS are described within WSDL although no one standard exists for JMS).
The diagram above depicts the Server Side architecture generally found in a Web Services Provider. The incoming transactions in this case are SOAP over some transport protocol. Its important to mention that the application server can have plug-ins where these plug-ins communicate with one or more internal or external resources. These resources can be Web Services and result in the plug-in being a consumer or the resource can be a SQL data source, or some non-web service oriented information repository.
Design-time and Run-time are differentiated by the requirement of finding services. In a design time operation an application developer will find the services that she was like to use through UDDI or some other mechanism. Once found the developer will consume the WSDL for the service to create a binding between their developed application and the web service. Run-time operations will commence and be entirely based on SOAP. In some cases clients will still interact with UDDI/WSDL to verify some information about the service. For example the UDDI/WSDL could be queried to determine if the service location has changed. Run-time hacking is where this presentation will primarily focus although development time resources like UDDI and WSDL will be necessary tools of the trade.
One common way of leveraging services is through a portal interface. The portal is responsible for creating the human presentation layer for a Service Oriented Architecture or one or more web services. Humans interact with the Portal Server using a browser client and the portal interacts with Web Services on their behalf. In some cases the web services interact further with back-end resources.
I’ve broken down web service threats into the following 4 basic bins for better understanding. The bins are basically based on the threat framework proposed by Shreeraj Shaw in the book titled “Hacking Web Services”. Transport: Transport layer threats involve the confidentiality and integrity of the data as well as concerns associated with erroneous routing and replay attacks. Denial of service is always an issue at the transport layer is no different when using web services. Parsing: Essentially this layer of threats is based on the idea of overwhelming the underlying XML parser. This is by far the easiest form of attack on XML application and has resulted in security vendors offering XDOS offerings to their products. Question: have you even opened a large recursive XML document in IE. If so you know that it essentially brings your machine to a stand still. Deployment: This is a really interesting area as it is greatly misunderstood. Web Services and their respective type of technology do many things automatically and are unknown to the application develop. For example many application servers will automatically return verbose error messages to clients as well as host WSDL documents describing their corresponding services for everyone to see. Openly available service descriptions, verbose error messages (potentially from the backend itself) and automated deployment are responsible for a majority of the threats associated with Web Services.