© Serhii Borodin/Shutterstock.com, © karloss/Shutterstock.com, © S&S Media
Windows Developer
Sicherheit schaffen für die REST-Architektur

Was tun gegen die REST-Unsicherheit?

Bei REST handelt es sich um den Representional State Transfer - welchen Rest denn sonst? Aber gibt es da überhaupt etwas zu schützen? Und wenn ja, wo und wie? Und wieso?

Carsten Eilers


Die Antwort ist ganz einfach: Natürlich gibt es auch bei REST etwas zu schützen; nämlich die Daten des Web Service. Wo müssen die geschützt werden? Während des Transports und auf dem Server, so wie eigentlich immer, wenn es um Websicherheit geht. Damit wäre auch schon das Wie geklärt: Wie bei einer Webanwendung. Und wieso? Na, weil sonst garantiert irgendwann ein Cyberkrimineller daherkommt und sich über den REST Service hermacht.

Los geht’s!

Zur Einführung verschaffen wir uns erst einmal einen kurzen Überblick darüber, was eine REST-Architektur ausmacht und was das für Ihre Sicherheit bedeutet: Eine REST-Architektur ist eine Client-Server-Architektur (so wie ja eigentlich fast alles im Web). Je nach Anwendungsfall müssen also Client und/oder Server authentifiziert und ggf. auch autorisiert werden. Außerdem ist REST zustandslos. Jeder Request enthält alle nötigen Informationen, um ihn zu verstehen; es werden keine Zustandsinformationen gespeichert, was bedeutet, dass auch die Authentifizierungs- und ggf. Autorisierungsinformationen mit jedem Request mitgeschickt werden müssen.

Da REST über HTTP kommuniziert, bietet es sich an, auf die HTTP Basic Authentication zurückzugreifen. Da dabei die Zugangsdaten als Klartext übertragen werden, führt das zwangsläufig dazu, dass die Verbindung über HTTPS abgewickelt werden muss, um ein Ausspähen der Zugangsdaten auf dem Transportweg zu verhindern. Optional kommt Code on Demand zum Einsatz, der erst bei Bedarf an den Client geschickt wird. Hier gilt wie immer im Web: Dieser Code darf keinen Schadcode, also zum Beispiel über XSS eingeschleuste Befehle, enthalten.

Das war es dann eigentlich auch schon, der Rest ist Business as usual: Wir benötigen eine Benutzerverwaltung und alle Daten müssen natürlich sicher gespeichert werden. Und bei Bedarf kann die Authentifizierung auch statt über die HTTP Basic Authentication zum Beispiel über die Prüfung der IP-Adresse des Clients oder HTTPS-Client-Zertifikate erfolgen.

Nicht so schnell

Da wir noch nicht am Ende dieses Artikels angekommen sind, dürfte das noch nicht alles gewesen sein. Und so ist es auch, auch wenn es damals, zu Beginn von REST, tatsächlich auf diese wenigen Punkte hinauslief. Aber dieses „Damals“ ist ja nun schon ein paar Jährchen her, REST basiert bekanntlich auf dem bereits 1994 von Roy Fielding entworfenen HTTP Object Model. Und die REST-Architektur selbst hat Roy Fielding auch schon 2000 in seiner Doktorarbeit beschrieben [1]. Inzwischen gibt es noch ein paar an...

Windows Developer
Sicherheit schaffen für die REST-Architektur

Was tun gegen die REST-Unsicherheit?

Bei REST handelt es sich um den Representional State Transfer - welchen Rest denn sonst? Aber gibt es da überhaupt etwas zu schützen? Und wenn ja, wo und wie? Und wieso?

Carsten Eilers


Die Antwort ist ganz einfach: Natürlich gibt es auch bei REST etwas zu schützen; nämlich die Daten des Web Service. Wo müssen die geschützt werden? Während des Transports und auf dem Server, so wie eigentlich immer, wenn es um Websicherheit geht. Damit wäre auch schon das Wie geklärt: Wie bei einer Webanwendung. Und wieso? Na, weil sonst garantiert irgendwann ein Cyberkrimineller daherkommt und sich über den REST Service hermacht.

Los geht’s!

Zur Einführung verschaffen wir uns erst einmal einen kurzen Überblick darüber, was eine REST-Architektur ausmacht und was das für Ihre Sicherheit bedeutet: Eine REST-Architektur ist eine Client-Server-Architektur (so wie ja eigentlich fast alles im Web). Je nach Anwendungsfall müssen also Client und/oder Server authentifiziert und ggf. auch autorisiert werden. Außerdem ist REST zustandslos. Jeder Request enthält alle nötigen Informationen, um ihn zu verstehen; es werden keine Zustandsinformationen gespeichert, was bedeutet, dass auch die Authentifizierungs- und ggf. Autorisierungsinformationen mit jedem Request mitgeschickt werden müssen.

Da REST über HTTP kommuniziert, bietet es sich an, auf die HTTP Basic Authentication zurückzugreifen. Da dabei die Zugangsdaten als Klartext übertragen werden, führt das zwangsläufig dazu, dass die Verbindung über HTTPS abgewickelt werden muss, um ein Ausspähen der Zugangsdaten auf dem Transportweg zu verhindern. Optional kommt Code on Demand zum Einsatz, der erst bei Bedarf an den Client geschickt wird. Hier gilt wie immer im Web: Dieser Code darf keinen Schadcode, also zum Beispiel über XSS eingeschleuste Befehle, enthalten.

Das war es dann eigentlich auch schon, der Rest ist Business as usual: Wir benötigen eine Benutzerverwaltung und alle Daten müssen natürlich sicher gespeichert werden. Und bei Bedarf kann die Authentifizierung auch statt über die HTTP Basic Authentication zum Beispiel über die Prüfung der IP-Adresse des Clients oder HTTPS-Client-Zertifikate erfolgen.

Nicht so schnell

Da wir noch nicht am Ende dieses Artikels angekommen sind, dürfte das noch nicht alles gewesen sein. Und so ist es auch, auch wenn es damals, zu Beginn von REST, tatsächlich auf diese wenigen Punkte hinauslief. Aber dieses „Damals“ ist ja nun schon ein paar Jährchen her, REST basiert bekanntlich auf dem bereits 1994 von Roy Fielding entworfenen HTTP Object Model. Und die REST-Architektur selbst hat Roy Fielding auch schon 2000 in seiner Doktorarbeit beschrieben [1]. Inzwischen gibt es noch ein paar an...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang