Security in REST Vulnerabilities and RESTful Security Mechanisms

1
Vulnerabilites of REST Services Vulnerabilit y Cause Attack Unvalidated input No validation mechanism to check input data SQL Injection to access database content Outdated protocols Old protocols are used Exploit the known weaknesses to attack client or server Man-in-the- Middle No secure communication channel Entire client/server communication is controlled by attacker No secure Malicious repitition of Security in REST – Vulnerabilities and RESTful Security Mechanisms Ashraf Abdo, Ibrahim Olanigan, Niklas Kolbe Service-Oriented Architecture, Lappeenranta University of Technology Introduction Representational State Transfer (REST) is an architectural style which is widely used to design Web Services. These RESTful services allow manipulation of resources on the web with a set of Unified Resource Identifiers (URIs). REST is based on the Hypertext Transfer Protocol (HTTP). Thus, RESTful services suffer from the same inconve-niences like most web applications. However, the set of constraints of REST which should be applied to the design of components do not include security issues. But the layered architecture of REST allows the integration of security mechanisms. This research poster shows the vulnerabilities of RESTful services and presents different security mechanisms to protect the services from these threads. RESTful Authorization Most of the existing security mechanisms violate the principles of a RESTful architecture. However, a proper security mechanism can not be implemented without certain non-RESTful elements to protect the service from the mentioned attacks. The following security mechanism includes as less non-RESTful elements and possible and also considers lightweight requirements for mobile clients. It consists of the following elements: 1) TLS connection with username and password 2) Safe password transfer and storage with hash and salt 3) Digital certificate to authorize user 4) Authentication token for access and resource requests 5) Symmetric key for message signatures 6) Expiry date to limit the session 7) User-bound timestamp to ensure message freshness Non-RESTful but essential elements are storage of userdata, the symmetric key and the expiry date as well as the user-bound timestamp. REST Security Protocol The REST security protocol aims to provide secure service communication. REST suffers from the absence of meta-descriptions concerning its security requirements. The existing security for the RESTful API rely on transport layer security and home-made message protection mechanism. However, it could be a burden for mobile systems and has the possibility of being error-prone. The security protocol is closely related to the WS-Security standard. The underlying principle is to achieve secure communication at the message level with minimum overheard. The protocol considers information as a set of multiparts and protocol headers. It uses a digital signature along with requests to provide confidentiality and non- repudiation. In addition, digital signature prevents unintentional or malicious modifications during the transmission. Hecate Architecture Hecate offers a framework to assure simplified handling of Authorization while keeping the potentials and flexibility of REST. The authorization framework consists out of a user model, representing the authorization mapping to the user credentials, and the Permission XML Document (PXD), representing different rules and their mapping to HTTP functionalities, resources and optional resource-aware filters. Hecate provides high flexibility: Any new resource ends up in a data-node. Further, one or multiple rule-nodes represent the permitted operations by linking to suitable perm-nodes which are created if not already existing. References Backere, F. D. et al., 2014. Design of a Security Mechanism for RESTful Web Service Communication through Mobile Clients, Ghent: IEEE. Graf, S., Zholudev, V., Lewandowski, L. & Waldvogel, M., 2011. Hecate, Managing Authorization with RESTful XML, s.l.: ACM. Serme, G., Oliveira, A. S. d., Massiera, J. & Roudier, Y., 2012. Enabling Message Security for RESTful Services. s.l., The red path in this map shows REST and Security in the context of Service Computing

description

How to secure RESTful applications

Transcript of Security in REST Vulnerabilities and RESTful Security Mechanisms

Page 1: Security in REST Vulnerabilities and RESTful Security Mechanisms

Vulnerabilites of REST ServicesVulnerability Cause Attack

Unvalidated inputNo validation mechanism to

check input data

SQL Injection to access database

content

Outdated protocolsOld protocols are

used

Exploit the known weaknesses to attack

client or server

Man-in-the-MiddleNo secure

communication channel

Entire client/server communication is

controlled by attacker

Replay attackNo secure

communication channel

Malicious repitition of valid data transmission to steal user identities

SpoofingSource of data has not to be

authorized

Person or program masquerades as

another to falsify data

Cross-Site ScriptingInfect client‘s

browser through web application

Steal authentication tokes or spoof content

of a client

Security in REST – Vulnerabilities and RESTful Security MechanismsAshraf Abdo, Ibrahim Olanigan, Niklas Kolbe

Service-Oriented Architecture, Lappeenranta University of Technology

IntroductionRepresentational State Transfer (REST) is an architectural style which is widely used to design Web Services. These RESTful services allow manipulation of resources on the web with a set of Unified Resource Identifiers (URIs).

REST is based on the Hypertext Transfer Protocol (HTTP). Thus, RESTful services suffer from the same inconve-niences like most web applications. However, the set of constraints of REST which should be applied to the design of components do not include security issues. But the layered architecture of REST allows the integration of security mechanisms.

This research poster shows the vulnerabilities of RESTful services and presents different security mechanisms to protect the services from these threads.

RESTful AuthorizationMost of the existing security mechanisms violate the principles of a RESTful architecture. However, a proper security mechanism can not be implemented without certain non-RESTful elements to protect the service from the mentioned attacks.

The following security mechanism includes as less non-RESTful elements and possible and also considers lightweight requirements for mobile clients. It consists of the following elements:

1) TLS connection with username and password2) Safe password transfer and storage with hash and salt3) Digital certificate to authorize user4) Authentication token for access and resource requests5) Symmetric key for message signatures6) Expiry date to limit the session7) User-bound timestamp to ensure message freshness

Non-RESTful but essential elements are storage of userdata, the symmetric key and the expiry date as well as the user-bound timestamp.

REST Security ProtocolThe REST security protocol aims to provide secure service communication. REST suffers from the absence of meta-descriptions concerning its security requirements. The existing security for the RESTful API rely on transport layer security and home-made message protection mechanism. However, it could be a burden for mobile systems and has the possibility of being error-prone.

The security protocol is closely related to the WS-Security standard. The underlying principle is to achieve secure communication at the message level with minimum overheard.

The protocol considers information as a set of multiparts and protocol headers. It uses a digital signature along with requests to provide confidentiality and non-repudiation. In addition, digital signature prevents unintentional or malicious modifications during the transmission.

Hecate ArchitectureHecate offers a framework to assure simplified handling of Authorization while keeping the potentials and flexibility of REST.

The authorization framework consists out of a user model, representing the authorization mapping to the user credentials, and the Permission XML Document (PXD), representing different rules and their mapping to HTTP functionalities, resources and optional resource-aware filters.

Hecate provides high flexibility: Any new resource ends up in a data-node. Further, one or multiple rule-nodes represent the permitted operations by linking to suitable perm-nodes which are created if not already existing.

ReferencesBackere, F. D. et al., 2014. Design of a Security Mechanism for RESTful Web Service Communication through Mobile Clients, Ghent: IEEE.

Graf, S., Zholudev, V., Lewandowski, L. & Waldvogel, M., 2011. Hecate, Managing Authorization with RESTful XML, s.l.: ACM.

Serme, G., Oliveira, A. S. d., Massiera, J. & Roudier, Y., 2012. Enabling Message Security for RESTful Services. s.l., IEEE 19th International Conference on Web Services.

The red path in this map shows REST and Security in

the context of Service Computing