Java Applikation als Backend (REST) absichern

[danielmaann]

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]

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]

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]

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.

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]

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]

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]

Was ist denn "Der falsche Client" ?

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

 

[Thallius]

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]

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

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]

Sicher? Afaik geht das durchaus...

 

[Thallius]

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]

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]

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

 

[mrBrown]

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

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]

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.

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

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]

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:

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]

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

 

[mrBrown]

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

 

[sascha-sphw]

Ich glaube wir reden aneinander vorbei.

 

[mrBrown]

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

 

[danielmaann]

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]

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]

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]

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:

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

 

[danielmaann]

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]

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.

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]

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]

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]

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