Discussion :

[genamiga]

Bonjour,


J'ai une application desktop écrite en Java qui se connecte à une base de données PostgreSQL via JDBC.

Maintenant je voudrais pouvoir consulter certaines données via une application mobile Android.

Je n'ai jamais rien écrit pour Android et j'aurais besoin d'aide.

Suite à mes recherches voici qlq questions/observations.

Bien que techniquement possible, il est fortement déconseillé d'utiliser une connexion JDBC "classique" parce que le login/mot de passe seraient exposés...Ok je comprends.

Il faut utiliser une API pour ce connecter...Ok

On parle souvent API REST...mais comment mettre ça en place très concrètement ?
Mais dans ce cas il faut faire des appels "particuliers" et on reçois les données en JSON (par exemple)...j'ai jamais travailler avec ça.
Je n'ai pas envie/le temps d'apprendre encore des technologies supplémentaires.

Il n'y a pas une solution de connexion sécurisée qui me permettrait ensuite de faire du JDBC comme j'en ai l'habitude ?
Bref, une solution qui ne s'occuperait QUE de la partie connexion.

Merci d'avance.

[grunk]

Bien que techniquement possible, il est fortement déconseillé d'utiliser une connexion JDBC "classique" parce que le login/mot de passe seraient exposés...Ok je comprends.

C'est exact. Il existe aussi le problème d'accès à la base. A partir du moment ou tu passe sur du mobile , il y'a de forte chance que tu sois en mobilité et donc hors du réseau de l'entreprise. JDBC impose donc d'ouvrir un port direct vers la bdd ce qu'en général on aime pas trop d'un point de vue sécurité.

On parle souvent API REST...mais comment mettre ça en place très concrètement ?

Tu peux le faire toi même ou utiliser un outils tout fait pour se genre de chose.
Par exemple :
https://github.com/PostgREST/postgrest
https://github.com/prest/prest
https://github.com/QBisConsult/psql-api

Si tu veux le faire toi même il faut mettre en place un serveur web qui va exposer des URL qui vont en fonction des paramètres chercher des données dans la base et le retourner dans le format que tu veux.

Mais dans ce cas il faut faire des appels "particuliers" et on reçois les données en JSON (par exemple)...j'ai jamais travailler avec ça.
Je n'ai pas envie/le temps d'apprendre encore des technologies supplémentaires.

Le JSON est juste un format , il est ce qu'était xml dans les années 2000 , autant dire que c'est incontournable aujourd'hui.

Maintenant coté android il existe des librairie qui permettent d'abstraire complètement l'utilisation d'une API REST et de simplement retourner des POJO.
Retrofit en est un exemple.
http://www.vogella.com/tutorials/Retrofit/article.html

Après rien ne t'interdit de faire du JDBC si ca te chante (et que les admin système l'autorise) , mais c'est pas la façon de faire. Perso je le déconseil ne serait ce que pour éviter que quelqu'un qui viendrait à décompiler l'appli mobile obtiennent l'architecture de la base, les mot de passes , etc ....

[genamiga]

C'est fou...pourquoi ne pas pouvoir utiliser JDBC...ça fonctionne parfaitement bien...

Donc pas question de faire un query SQL et récupérer ces données via des resultsets...

Faut écrire une requête (qui n'a rien a voir avec du SQL), avec l'API xxx et récupérer les données (de la BDD SQL) dans le format à la mode...jusqu'à la mode suivante.

C'est n'importe quoi...

[fr1man]

Tu peux aussi donner la clé de chez toi aux facteurs/livreurs au lieu de la clé de la boite au lettres.
Ca fonctionne tout aussi bien

Comme cela a été dit, tant que possible, on ouvre le moins de ports possibles vers l'extérieur.
Généralement, les ports http/https.
La base de données est souvent sur un serveur différent du serveur qui héberge le web service, pour éviter de l'exposer en direct.
Imagine si tu as plusieurs applications et beaucoup de données de différentes sources dans ta base, tu n'aimerais pas qu'on puisse potentiellement avoir accès à tout.

Je comprends ta frustration, mais écrire un webservice n'est pas très compliqué.
Quelques lignes de php, node js et c'est fait, si tu trouves trop lourd de le faire en java.

[genamiga]

Pour l'API de connexion pREST à l'air bien...je viens de faire un test et ça me renvoie bien les données en JSON.

Reste à les lire...refaire les classes...

Lire les données en JSON...avec quoi ?

json.org ?


PS : C'est en effet extrêmement frustrant de devoir refaire mes classes et de ne pas pouvoir faire de query SQL classiques...

[grunk]

C'est n'importe quoi...

Ce qui est n'importe quoi c'est de ne pas voir le risque de sécurité monumentale que représente une connexion JDBC sur un mobile.

Json c'est pas une mode c'est LE format standard intéropérable utilisé par tout le monde (officiellement dispo depuis 2002). XML est enterré depuis des années.

Lire les données en JSON...avec quoi ?
json.org ?

Oui.
Encore une fois soit tu te cogne le client http et le parser json à la main (moyennement intéressant) soit tu passes par une lib tierce qui abstrait tout pour toi et qui te retourne des objets tout prêt (et y'a des chances que tu puisse réutiliser une bonne partie de tes classes métiers).
Par exemple retrofit :
http://square.github.io/retrofit/
Un peu plus de détail : http://www.vogella.com/tutorials/Retrofit/article.html

Si tu veux continuer à écrire des requêtes tu peux aussi regarder du coté de GraphQL au lieu de REST mais vu ton aversion pour la nouveauté , ca risque de vite te rebuter

[genamiga]

Je comprend très bien qu'il faut sécuriser la connexion sur du mobile.

Mais concrètement qu'est ce que ça apporte de changer la façon de récupérer les données ?

[grunk]

Appli mobile en JDBC :

Je décompile l'application : je récupère :
- Le port de connexion à la base
- L'architecture de la base
- Identifiant / mdp de connexion à la base (puisque en général il n'aura pas été protégé correctement)

Ma base est ouverte sur l'extérieur et donc potentiellement attaquable.
Avec les identifiants et le port JDBC je peux venir faire des requêtes non prévue par le soft et potentiellement outrepasser des limitations mise en place par le logiciel.
On peut imaginer un DDOS qui met à genoux toute mon organisation parce que la base est tombé


Appli avec Web service :
Je décompile l'application : je récupère :
- Une clé API et ou identifiant d'accès au web service (puisque en général il n'aura pas été protégé correctemen
- Éventuellement la structure des objets métiers

Si mon appli est compromise à aucun moment ma base n'est en péril. Si je suis attaqué , au pire des cas je coupe le webservice et toute mon organisation interne peut continuer à travailler sur la base.
A aucun moment un attaquant ne pourra venir faire une requête non prévue sur la base.

[genamiga]

J'ai bien compris qu'il ne faut pas exposé Identifiant / mdp de connexion à la base, je suis parfaitement d'accord avec toi...depuis le début

Il faut bien sûr séparer la partie connexion.

Mes interrogations se portent plus sur la récupérations des données.

Appli avec Web service :
Je décompile l'application : je récupère :
- Une clé API et ou identifiant d'accès au web service (puisque en général il n'aura pas été protégé correctemen
- Éventuellement la structure des objets métiers

A partir de là qu'est ce qui empêche un attaquant de faire toutes les requêtes qu'il veut ?

Avec pREST par exemple, il est possible de récupérer :
- le nom de toutes les bases
- le nom de toutes les tables d'une base
- toutes les données des colonnes non protégées au niveau de la base

Au final, pas de grosses différences...non ?

Au niveau de la base on peut :

- gérer sur les privilèges des utilisateurs (SELECT, INSERT, UPDATE, DELETE, ...), au niveau des bases, des tables et des colonnes
- limiter le nombres de connexions

Mais c'est sûr que l'on peut couper le webservice...c'est une petite sécurité en plus.

[Pill_S]

A partir de là qu'est ce qui empêche un attaquant de faire toutes les requêtes qu'il veut ?

En général, chaque endpoint est ouvert uniquement aux profils adéquats. Interdiction aux users lambda de lancer un DELETE sur la resource /orders. Ils se prendront un 403.

Un peu comme s'il y avait un VPD avec les grants adéquats sur chaque table pour chaque profil en fait.

On peut aussi, via des mod Apache (ou autre), mettre tout un tas de règles en place. Par exemple, interdiction de brut forcer "/login" (max 5 tentatives en 10 mintues). Ou toute violation du protocole http se termine forcément en bad request. Ou d'autres...

Ou crypter les communications (https) même si la db ne le supporte pas.

Et aussi, supporter 100000 utilisateurs concurrents avec seulement 50 connexions db.

Et mettre en place du cache

...

[grunk]

A partir de là qu'est ce qui empêche un attaquant de faire toutes les requêtes qu'il veut ?

Avec pREST par exemple, il est possible de récupérer :
- le nom de toutes les bases
- le nom de toutes les tables d'une base
- toutes les données des colonnes non protégées au niveau de la base

Au final, pas de grosses différences...non ?

C'est parce que tu utilise un webservice tout fait qui ne fait que exposer la base de données à l’extérieur.
Si on veux bien faire ton webservice ne doit pas disposer de toute ces fonctionnalités et doit répondre que aux requêtes pour lequel il est prévu. Lister les bases et les tables c'est par exemple un non sens.

Il est évident que chaque utilisateur sur la base à les droits qui lui sont propres.
Mais ca veux pas dire que je souhaite que mon utilisateur ai le droit de voir toutes les données d'une table/vue malgré le droit de select qui lui est associé.

Je prend un exemple concret.

Admettons que j'ai une table "users" , et j'ai décider que depuis l'appli mobile je ne pouvais voir que 25 utilisateurs de cette table.

Dans mon appli en JDBC je vais donc faire un SELECT * FROM users LIMIT 0,25 (par exemple).
Dans mon appli en webservice je vais faire une requêtes sur /users/list (par exemple).

Maintenant admettons , que quelqu'un est réussi à récupérer toutes les données de mon applis.
Il décide de recoder sa propre appli.

Avec JDBC , il va s'implement réécrire la requête de sélection comme ça lui chante. Il n'aura pas de problème puisque l'utilisateur à le droit de SELECT sur la table.
Avec le webservice , il n'aura pas d'autre choix que d'utiliser l'url qui renvois la liste d'utilisateurs et ne pourras pas agir sur les données retournée.

Après effectivement si le webservice permet simplement d'écrire une requête SQL en passant des paramètres ça n'a que très peut d'intérêt , si ce n'est complexifier la communication.

Les bonnes pratiques veulent qu'on passe par un webservice , après ce n'est qu'une recommandation , chacun fait bien comme il à envie.

[genamiga]

En effet, pREST expose tout le serveur par défaut mais on peut gérer les permissions https://postgres.rest/permissions/

Avec PostgreSQL il y a aussi les permissions par colonnes. Cela rend impossible les SELECT * FROM table

Bref au final, ce que je voulais dire c'est que la façon de transférer les données de la BDD vers l'application via un webservice n'apporte pas de sécurité supplémentaire.

Dans le cas d'une application desktop et une application mobile cela impose de devoir réécrire et surtout maintenir deux façons de transférer les données. Il y a 78 tables dans ma BDD principale...je n'ai pas besoin de tout sur mobile mais bon...

C'est ça que je trouve ridicule.

Évidement si on a QUE une application mobile ou si on a pas d'application desktop existante depuis des années et à maintenir...cela ne pose pas de problème...on écrit tout avec le webservice sans se poser de questions.

C'est bien dommage qu'il n'y ai pas une solution intermédiaire, pour se connecter de façon sécuriser (webservice) et récupérer les données avec les classes existantes. Cela permettrait de ne pas devoir maintenir deux façons de faire la même choses.

[grunk]

Après y'a sans doute moyen de sécuriser une connexion JDBC.
En stockant les identifiant dans du code C accessible via JNI et si possible de manière obfusqué (pas une simple string) on se prémunie déjà du risque de décompilation.
Après il faut juste que la connexion JDBC se fasse over SSL (je connais pas les possibilités de jdbc , mais j'imagine que c'est possible) pour éviter que les données soient interceptée sur le réseau.

Dans le cas d'une application desktop et une application mobile cela impose de devoir réécrire et surtout maintenir deux façons de transférer les données

C'est le problème quand on maintient des applications anciennes , c'est toujours moins facile de les interfacer avec les technos modernes.