# On the Need for a General REST-Security Framework
## 4 REST-Security Demands and Specifics
### REST-Security Specifics  
Although both security stacks have their similarities, the plain adoption of WS-security to REST and instantiations of REST is not feasible in a straightforward manner. The specifics of REST have to be considered carefully in order to obtain a suitable and seamless security for REST-based services. What needs to be taken into account first is the abstraction layer of REST and its instantiations. REST itself is a very general concept and needs to be handled accordingly. Thus, a simple mapping of the concrete WS-Security technologies to construct REST-security is not feasible, since both reside on different abstraction layers. Since REST represents an abstract model, security components for this architectural style need to be considered and defined on the same abstraction layer as well. Consequently, REST-security needs to be a general framework composed of definitions, structures and rules on how to protect REST-based systems. The term general in this context has to be understood as generic in the sense that the schemes contained in the REST-security framework are not bound to a specific REST-based technology or protocol only, but are applicable to any REST-ful technology. Such a general REST-security framework would then support a guided adoption and implementation to any concrete REST-ful protocol (see Figure 6). Another REST specific issue is that there is no self-contained REST message, but the relevant data items are scattered around the service protocol and the service payload (see Figure 7). SOAP messages,  
Figure 5: Desired security stack for REST-based web services [13]. in contrast, are a self-contained XML structure. Both the meta-data as well as the payload in form of a service operation or its corresponding result are enclosed in one XML document. Thus, with the application of security mechanisms based on the technologies shown in Figure 4, both message parts can be covered. This is, however, not the case for REST messages. Referring again to REST-ful HTTP as an example, the meta-data is included in the HTTP header, whereas the resource representation is inside the HTTP body. Since both parts are disjoint for many reasons, distinct security mechanisms need to be applied in a balanced manner. If this is not being recognized, novel vulnerabilities might be exploitable in the future. Table 1 shows a set of possible attack vectors, which can be applied to REST-ful HTTP messages that do carry a protected body only. The assumed attacker model is a common man-in-the-middle (MITM) attack, in which an intruder is able to tamper the whole HTTP request and response messages due to exploited transport security vulnerabilities or a compromised intermediate system. Attack #1 is based on a GET request that does not contain a resource representation. Thus, the whole HTTP message remains unprotected providing the surface for a malicious twist of the GET method by, e.g., the DELETE method. The second attack tampers the resource path and the host header with the aim of redirecting a client to the attacker's resource. The attack in row three emphasizes that even if a message includes a protected body, an attacker is still able to spoof the unsecured header. In the provided case, the attacker can manipulate the HTTP method and the content-length header in order to construct a valid DELETE request. Moreover, a malicious replacement of a resource representation is also feasible as shown in row four. Here, an adversary can substitute a resource representation with its own resource representation. Similar attacks are also possible on responses. Row five depicts an example, where the location header is changed in order to forward a client to a  
Figure 6: Instantiation of the general REST-security framework to specific REST-ful protocols. Figure 7: Comparison of the SOAP-based service message structure with a REST service message structure exemplified by a REST-ful HTTP instantiation. malicious resource. The attack in row 6 presents a deception of the cache behavior.