# Java Applikation als Backend (REST) absichern



## danielmaann (21. Jul 2017)

Hallo zusammen

Gestern hatte ich ein Gespräch mit einem erfahrenen Entwickler im Betrieb. Ich selbst arbeite als Softwareentwickler mit Java und anderen Technologien. Nun kam das Thema auf "Backend absichern". Es istz schwer zu erklären wie es gemeint ist, jedoch versuche ich es mit beispielen.

Es ist so:
- Mein Wissensstand war:
Wenn man eine Frontenedapplikation hat welche mit einem Backend komuniziert über die URL (via REST) kann man diese Frontendapplikation entschüsseln und man sieht die Backendurl.
Nun kann in diesem Fall dieser mit dem Endpoint mit dem Browser, oder Postman oder was auch sonst über diese REST Schnittstelle kommunizieren. Auch wenn ich im Backend ein Token habe, kann es halt denselben Token vewenden und als Header mit geben.

- Der erfahrere Entwickler sagte:
Dies ist so, aber dies ist nicht abgesichert. Man kann wie eine Sicherung über die Backend applikation legen, welche ein verschlüsseltes Token mit gibt, somit ist das dann unmöglich. Und nur die Frontendapplikation kann kommunizieren.

Nun frage ich mich, wieso sollte man diesen verschlüsselten Token auch nicht nehmen können und diesen mit Postman oder so mit geben? Wie funktioniert das? Gibt es dafür Frameworks oder Libraries?

Kann mir jemand das besser erklären?


----------



## Thallius (21. Jul 2017)

Am einfachsten indem du den verschlüsselten Token abhängig machst von einem Login am Frontend. Sprich, der User der Frontend Applikation muss einen Login eingeben um sich mit dem Backend verbinden zu können.

Gruß

Claus


----------



## danielmaann (21. Jul 2017)

Thallius hat gesagt.:


> Am einfachsten indem du den verschlüsselten Token abhängig machst von einem Login am Frontend. Sprich, der User der Frontend Applikation muss einen Login eingeben um sich mit dem Backend verbinden zu können.
> 
> Gruß
> 
> Claus


Verstehe ich das richtig, das in diesem Fall dieses Token jedesmal mitgesendet wird und somit wie eingeloggt wird jedesmal... aber dieses token kann man ja auch kopieren und dann via Postman verwenden


----------



## mrBrown (21. Jul 2017)

danielmaann hat gesagt.:


> Wenn man eine Frontenedapplikation hat welche mit einem Backend komuniziert über die URL (via REST) kann man diese Frontendapplikation entschüsseln und man sieht die Backendurl.
> Nun kann in diesem Fall dieser mit dem Endpoint mit dem Browser, oder Postman oder was auch sonst über diese REST Schnittstelle kommunizieren. Auch wenn ich im Backend ein Token habe, kann es halt denselben Token vewenden und als Header mit geben.


Was ist denn daran das Problem? In den meisten Fällen ist es völlig irrelevant, welcher Client genutzt wird - und in den anderen Fällen ist häufig das Backend nicht sicher genug gegen invalide Eingaben, dass sollte aber Backendseitig gelöst werden, nicht Clientseitig.




Thallius hat gesagt.:


> Am einfachsten indem du den verschlüsselten Token abhängig machst von einem Login am Frontend. Sprich, der User der Frontend Applikation muss einen Login eingeben um sich mit dem Backend verbinden zu können.


Das hilft gegen seinen genannten Fall nicht. Es geht nicht um den falschen Nutzer, sondern um den falschen Client


----------



## Thallius (21. Jul 2017)

mrBrown hat gesagt.:


> Was ist denn daran das Problem? In den meisten Fällen ist es völlig irrelevant, welcher Client genutzt wird - und in den anderen Fällen ist häufig das Backend nicht sicher genug gegen invalide Eingaben, dass sollte aber Backendseitig gelöst werden, nicht Clientseitig.
> 
> Das hilft gegen seinen genannten Fall nicht. Es geht nicht um den falschen Nutzer, sondern um den falschen Client



Was ist denn "Der falsche Client" ?


----------



## Flown (21. Jul 2017)

Wenn man den Token besitzt, dann kann man sich immer am Server authentifizieren. Die Frage ist, wie man an den Token kommt.
Wenn man ihn mit MITM Attacken bekommt hilft ungemein eine verschlüsselte Verbindung (z.B. TLS).
Wenn man ihn weitergibt, dann gibts keine Absicherung.


----------



## mrBrown (21. Jul 2017)

Thallius hat gesagt.:


> Was ist denn "Der falsche Client" ?


Steht oben, zB Postman statt richtiger Anwendung. Bedient wird beides vom gleichem User.


----------



## Thallius (21. Jul 2017)

danielmaann hat gesagt.:


> Verstehe ich das richtig, das in diesem Fall dieses Token jedesmal mitgesendet wird und somit wie eingeloggt wird jedesmal... aber dieses token kann man ja auch kopieren und dann via Postman verwenden



Nein der User logged sich auf dem Backend ein und dabei wird immer ein neues Token generiert welches für die zukünftige Kommunikation genutzt wird. Sobald sich der User ausloggt wird das Token natürlich invalide. genauso wenn sich die IP des Senders ändert oder nach einer gewissen Zeit untätigkeit. Im Prinzip nichts anderes als eine Session bei einer Webapplikation.

Beispiele für so etwas sind oAuth, openID o.ä.

Gruß

Claus


----------



## danielmaann (22. Jul 2017)

Thallius hat gesagt.:


> Nein der User logged sich auf dem Backend ein und dabei wird immer ein neues Token generiert welches für die zukünftige Kommunikation genutzt wird. Sobald sich der User ausloggt wird das Token natürlich invalide. genauso wenn sich die IP des Senders ändert oder nach einer gewissen Zeit untätigkeit. Im Prinzip nichts anderes als eine Session bei einer Webapplikation.
> 
> Beispiele für so etwas sind oAuth, openID o.ä.
> 
> ...


Danke für deinen Beitrag jedoch hilft das bei meinem Problen nicht weiter. Nimm mal die Facebook App, dekompiliere sie und dann probiere über die REST Schnittstelle auf facebook zuzugreifen (mit allen Daten die du auch in der App hast, Token und so weiter).. Es wird nicht funktionieren .. das will ich auch so haben


----------



## mrBrown (22. Jul 2017)

Sicher? Afaik geht das durchaus...


----------



## Thallius (23. Jul 2017)

Selbst wenn nicht, dann kann man im Code herausfinden was man machen muss damit es geht. Ich denke die werden da schon noch ein paar zusätzliche Sicherheiten eingebaut haben. Wenn sich deine Software gegenüber dem FB Server genauso verhält wie die App, dann wird sie auch die Daten bekommen.


----------



## sascha-sphw (21. Aug 2017)

In der Adminkonsole der Facebook App legt man die Domain der App fest, zusätzlich kann man auch die IP festlegen. Wenn dann Anfragen über eine andere IP als die eingetragene kommen, werden sie blockiert. Zusätzlich kann man aber auch noch explizit IP Adressen blockieren.


----------



## sascha-sphw (21. Aug 2017)

Achso, und einen Geheimcode, den die App nicht im Client Code aufbewahrt wird ebenfalls noch an FB geschickt.


----------



## mrBrown (21. Aug 2017)

sascha-sphw hat gesagt.:


> In der Adminkonsole der Facebook App legt man die Domain der App fest, zusätzlich kann man auch die IP festlegen. Wenn dann Anfragen über eine andere IP als die eingetragene kommen, werden sie blockiert. Zusätzlich kann man aber auch noch explizit IP Adressen blockieren.


Ist aber was anderes, als das vom TO beschriebene



sascha-sphw hat gesagt.:


> Achso, und einen Geheimcode, den die App nicht im Client Code aufbewahrt wird ebenfalls noch an FB geschickt.


Er liegt aber trotzdem beim Client -> hat man volle Kontrolle über den Client, kommt man an den Token.


----------



## sascha-sphw (21. Aug 2017)

Ich beziehe mich auf die folgende Aussage. Und wollte deshalb nur erwähnt haben, dass FB hier mehr macht als einen simplen Token den man über einen Login bekommt.


danielmaann hat gesagt.:


> Nimm mal die Facebook App, dekompiliere sie und dann probiere über die REST Schnittstelle auf facebook zuzugreifen (mit allen Daten die du auch in der App hast, Token und so weiter).. Es wird nicht funktionieren .. das will ich auch so haben





mrBrown hat gesagt.:


> Er liegt aber trotzdem beim Client -> hat man volle Kontrolle über den Client, kommt man an den Token.


Wenn Du den Geheim Code trotz Sicherheitshinweise von FB im Client Code aufbewahrst, dann schon. Sollte man aber nicht machen...
https://developers.facebook.com/docs/facebook-login/security#appsecret


----------



## mrBrown (21. Aug 2017)

sascha-sphw hat gesagt.:


> Ich beziehe mich auf die folgende Aussage. Und wollte deshalb nur erwähnt haben, dass FB hier mehr macht als einen simplen Token den man über einen Login bekommt.


*Was* sollen sie denn machen?
Beschränkung auf eine IP ist bei der Facebook-App ganz offensichtlich nicht möglich, bei um die Milliarde Nutzer...

Und zu dem Geheimcode:


sascha-sphw hat gesagt.:


> Wenn Du den Geheim Code trotz Sicherheitshinweise von FB im Client Code aufbewahrst, dann schon. Sollte man aber nicht machen...
> https://developers.facebook.com/docs/facebook-login/security#appsecret


Ich sagte "Client", nicht "Code".
In dem von dir geposteten Link ist der Client der App-Server, und auf genau dem liegen die Codes...

Und wo bringt man denn zB den Geheimcode in der App (auf die du dich ja bezogen hast) unter, wenn nicht in der App (=Client)?


----------



## sascha-sphw (21. Aug 2017)

Welche App ist denn gemeint? Die native FB App auf Mobilen Geräten, oder diese hier https://developers.facebook.com?


----------



## mrBrown (21. Aug 2017)

Unerheblich, bis auf die mögliche Beschränkung auf IPs gilt das für alle Arten von Clients


----------



## sascha-sphw (21. Aug 2017)

Ich glaube wir reden aneinander vorbei.


----------



## mrBrown (21. Aug 2017)

Kommt drauf an wovon du redest, ich beziehe mich auf das Thema dieses Threads...


----------



## danielmaann (22. Aug 2017)

Schade das es da nun Diskussionen gibt. Naja ist wahrscheinlich so, dass ihr wirklich aneinander vorbei redet. Um es zu vereifachen.

Ich will sicherstellen, das mein Backend nur von meiner App aus abgerufen werden kann. Bzw. abfragen auf die Restschnittstelle sollten nur von der App passieren können und nicht von einem anderen Client (Postman,...). Also Ich habe dazu gehört, das dies mit einem Token funktionieren würde. Aber mit noch etwas zusätzlichem, ohne das man diesen token einfach kopieren kann (mit MITM oder wie auch immer) und diesen dann für den falschen Client wieder verwenden kann.


----------



## Dukel (22. Aug 2017)

Ich glaube das kannst du nicht verhindern. Alles was auf einem Client ist kann kopiert werden.

Wieso darf die Schnittstelle nur von deinem Client aus angesprochen werden?


----------



## danielmaann (22. Aug 2017)

Dukel hat gesagt.:


> Ich glaube das kannst du nicht verhindern. Alles was auf einem Client ist kann kopiert werden.
> 
> Wieso darf die Schnittstelle nur von deinem Client aus angesprochen werden?


Um sicher zu gehen, das nur dieser Client mit dem Backend kommuniziert um den Zugriff von Clients welche nicht von mir sind, zu verweigern.


----------



## mrBrown (22. Aug 2017)

danielmaann hat gesagt.:


> Um sicher zu gehen, das nur dieser Client mit dem Backend kommuniziert um den Zugriff von Clients welche nicht von mir sind, zu verweigern.



Bleibt die Frage:


Dukel hat gesagt.:


> Wieso darf die Schnittstelle nur von deinem Client aus angesprochen werden?


----------



## danielmaann (22. Aug 2017)

mrBrown hat gesagt.:


> Bleibt die Frage:


Weil ich der einzige sein will, der mit der Restschnittstelle kommuniziert. Somit kann auch verhindert werden, das jemand nicht unzählige requests absetzt von seiner eigenen applikation.


----------



## mrBrown (22. Aug 2017)

danielmaann hat gesagt.:


> Weil ich der einzige sein will, der mit der Restschnittstelle kommuniziert.


Das fällt unter Nutzer-Authentifizierung, und hat nichts mit Begrenzung auf Clients zu tun.



danielmaann hat gesagt.:


> Somit kann auch verhindert werden, das jemand nicht unzählige requests absetzt von seiner eigenen applikation.


Das lässt sich auch mit einfacher Nutzer-Authentifizierung lösen, uU unter Zuhilfenahme von anderen Techniken.


----------



## Dukel (22. Aug 2017)

Du hast Clients grundsätzlich nicht im Griff. Daher muss deine Applikation / App Server sicher sein. Wenn eine Bedrohung unzählige Zugriffe (DOS / DDOS, kann auch ohne deinen Client passieren, in dem dein App Server dauernd abgefragt wird) ist dann muss man dagegen was machen. Eine Möglichkeit ist die Zugriffe zu begrenzen.


----------



## danielmaann (22. Aug 2017)

Dukel hat gesagt.:


> Du hast Clients grundsätzlich nicht im Griff. Daher muss deine Applikation / App Server sicher sein. Wenn eine Bedrohung unzählige Zugriffe (DOS / DDOS, kann auch ohne deinen Client passieren, in dem dein App Server dauernd abgefragt wird) ist dann muss man dagegen was machen. Eine Möglichkeit ist die Zugriffe zu begrenzen.


Und wie werden die zugriffe begrenzt? werden die reinprogrammiert mit java, nun bei spring oder gibts da auf dem server eine config file dafür und wie wird der zugriff begrenzt? generell, pro sekunde, pro stunde, pro user? oder wie funktioniert das?


----------



## mrBrown (22. Aug 2017)

danielmaann hat gesagt.:


> Und wie werden die zugriffe begrenzt? werden die reinprogrammiert mit java, nun bei spring oder gibts da auf dem server eine config file dafür und wie wird der zugriff begrenzt? generell, pro sekunde, pro stunde, pro user? oder wie funktioniert das?


Such dir eins aus deinem genannten aus, umsetzbar ist alles


----------

