Coucou les pottos !

J'aimerais accèdér a une base de données depuis une application android, j'ai trouvé ceci sur le net :

http://codes-sources.commentcamarche.net/faq/10789-connecter-une-application-android-a-une-base-de-donnees

donc en gros faut heberger une page internet pour accèder a la base ?

et on fait quoi concernant la sécurité ? Une personne qui m'est un oeil a la page a accès aux éléments de sécurité non ?

a tous les pros en dev android / web si j'ai posé des questions qui peuvent vous paraitre bète mais je suis vraiment un gros débutant dans ces trucs la.


GT Pas secure !!
avatar< SCPCD > j'aurais du dire "les doigts dans le cul vu que le java c'est de la merde"
Je suis Goto !
Je ne sais pas ce que te diront les spécialistes de développement mobile (que je ne suis pas), mais personnellement, je trouve cette solution absolument exécrable. On peut parfaitement utiliser au moins les bibliothèques client de MySQL dans l'application Android (et si le problème est la licence, il y a des connecteurs C et Java sous LGPL du projet MariaDB qui marchent aussi avec les serveurs MySQL). Et puis je n'utiliserais une base de données distante que si c'est absolument nécessaire pour le fonctionnement de l'application (genre la synchronisation entre plusieurs appareils), sinon, une base de données locale (probablement un truc embarqué comme SQLite, voire Derby Embedded si on veut absolument faire tout en Java) est quand-même plus au service de l'utilisateur.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
La base de données doit être distante pour des raisons de places sinon je l'aurais 'embarqué' sans soucis, mais j'ai pas le choix sinon j'aurais pas posé cette question ici smile


GT distant magic
avatar< SCPCD > j'aurais du dire "les doigts dans le cul vu que le java c'est de la merde"
Je suis Goto !
Utilise au moins les bibliothèques client alors, ça ne sert à rien de passer par une webapp.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Désolé, je n'ai pas lu ce topic avant, donc je ne sais pas si la question est encore d'actualité sorry
En tout cas, oui, si tu dois héberger et accéder à une base de données tu ferais mieux de ne pas l'exposer à l'air libre sur internet. (C'est pas une question Android du tout en réalité, mais une question d'architecture ^^)
Il est conseillé de créer une "page web", en général dans l'ère moderne plutôt sous la forme d'une API REST, pour des raisons de sécurité, mais aussi pour des raisons de simplicité. (Ton API peut être utilisée par n'importe quelle autre application autorisée)
Côté sécurité, si tu exposes ta base de données directement sur internet:
  • Tu vas également exposer publiquement le compte et le mot de passe que tu utilises pour t'y connecter. (On le trouvera dans le code de ton application)
  • Selon les droits du compte, c'est un peu open-bar avec ta base, et celui qui s'y connectera y fera ce qu'il voudra avec les droits qu'il aura.
  • Même si tu utilises un compte "limité" pour accéder à ta base, à part avec un compte en lecture seule, on pourra toujours faire des trucs que tu ne voudrais pas qu'on fasse (au minimum modifier tes données sans ton consentement)
  • Quand bien même, il y aura toujours la possibilité que quelqu'un ne découvre ton mot de passe administrateur et s'y connecte. Et là, il pourra foutre le boxon dans ta base comme bon lui semblera.
  • Sincèrement, "personne" ne fait ça. (Non, j'ai pas été vérifier partout, mais vraiment…) C'est une incitation au crime. Particulièrement chez les développeurs, si on peut analyser la composition d'une application on hésitera pas. Voir quelqu'un se connecter à une base de données à travers internet, ça titille vraiment. En plus, il y aura forcément un mot de passe visible en clair quelque part.
  • Tu peux probablement compter sur le fait que les protocoles de base de données ne soient pas sécurisés (certains le sont, c'est pas obligatoire, et chez ceux qui le font, c'est peut-être payant)

En dehors de l'aspect sécurité, tu peux pratiquement être certains que les protocoles d'accès aux bases de données ne sont pas optimisés pour la latence d'internet.

De fait, ce que "tu dois" faire (tu es libre, mais c'est vivement conseillé), c'est effectivement te créer une petite interface HTTP accessible sur le web. (Là tu peux te documenter un peu sur les API RESTful / JSON de manière plus générale que l'exemple succint donné dans ton lien. Mais j'ai conscience que ça va faire un peu lourd sad)
L'idée c'est que le code que tu va héberger sur le serveur web ne sera accessible qu'à toi (puisque tu es le seul à pouvoir modifier son contenu), et même s'il contient les mots de passe d'accès à la base (si possible pas le mot de passe admin, quand même), personne ne pourra les voir.
Maintenant, on peut faire plus sécurisé… C'est de bon goût de ne pas laisser n'importe qui utiliser à ta petite API/base de données… Et si tu peux, c'est bien d'avoir un genre de gestion d'utilisateurs (encore via API du coup tongue) qui te permettre au niveau de ton API d'autoriser ou de refuser les requêtes. C'est même plutôt obligatoire si tu comptes aussi accéder à ta base en écriture.

Enfin voilà, c'est du développement back-end. Ça semble demander beaucoup pour peu de choses, mais c'est nécessaire si tu veux protéger tes données.
Malgré tout, j'ai l'impression que tu ne veux que de la lecture seule, donc sauf besoin de confidentialité, ça ne devrait pas être trop contraignant pour toi non plus.
Bon courage wink
avatarLe scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes
GoldenCrystal (./5) :
En tout cas, oui, si tu dois héberger et accéder à une base de données tu ferais mieux de ne pas l'exposer à l'air libre sur internet. (C'est pas une question Android du tout en réalité, mais une question d'architecture ^^)
Et la page web, elle n'est pas exposée à l'"air libre"? À mon avis, c'est juste une surcouche de plus qui pourrait être attaquée (à condition que la structure de la BDD soit adaptée à l'accès direct, je vais y venir!).
Il est conseillé de créer une "page web", en général dans l'ère moderne plutôt sous la forme d'une API REST, pour des raisons de sécurité, mais aussi pour des raisons de simplicité. (Ton API peut être utilisée par n'importe quelle autre application autorisée)
Côté sécurité, si tu exposes ta base de données directement sur internet:
  • Tu vas également exposer publiquement le compte et le mot de passe que tu utilises pour t'y connecter. (On le trouvera dans le code de ton application)
Donc tu proposes de remplacer un compte et mot de passe pour une BDD par un compte et mot de passe pour une application web? On y a gagné quoi? Et en plus, maintenant, c'est à ton application de réinventer l'authentification alors que la BDD serait déjà capable de le faire pour toi.
  • Selon les droits du compte, c'est un peu open-bar avec ta base, et celui qui s'y connectera y fera ce qu'il voudra avec les droits qu'il aura.
  • Même si tu utilises un compte "limité" pour accéder à ta base, à part avec un compte en lecture seule, on pourra toujours faire des trucs que tu ne voudrais pas qu'on fasse (au minimum modifier tes données sans ton consentement)
Le cas qu'il décrit, c'est que la BDD est remote pour des raisons de place, pas pour échanger des données entre utilisateurs. Donc tu crées une BDD totalement séparée pour chaque utilisateur et tu ne donnes accès à ce compte qu'à cette BDD. (En principe, tu peux même lui donner ALL PRIVILEGES sur cette BDD, c'est sa BDD, il en fait ce qu'il veut.)

Si on a besoin d'une BDD partagée, alors là oui, il faut un wrapper qui limite l'accès, mais ce wrapper peut aussi être une vue (ou un ensemble de vues) SQL, plus éventuellement des tables privées par utilisateur. Les BDD permettent de donner les permissions de manière assez fine si l'application est conçue convenablement. Mais bien sûr, si tu veux faire un SELECT * FROM all_users where user = "toto@example.com"; depuis l'application client, ça ne va pas aller du tout, on est bien d'accord là!
  • Quand bien même, il y aura toujours la possibilité que quelqu'un ne découvre ton mot de passe administrateur et s'y connecte. Et là, il pourra foutre le boxon dans ta base comme bon lui semblera.
Si ton compte administrateur MariaDB est root@localhost, il a beau avoir le mot de passe, il ne pourra pas se connecter depuis une machine extérieure. Le compte admin peut être restreint à localhost même quand tous les autres comptes sont ouverts au monde. Et puis faut pas utiliser des mots de passe trop simples pour les comptes admin. Ça vaut aussi pour le compte root du système d'exploitation, le compte admin de la webapp s'il y en a un, etc.
  • Sincèrement, "personne" ne fait ça. (Non, j'ai pas été vérifier partout, mais vraiment…) C'est une incitation au crime. Particulièrement chez les développeurs, si on peut analyser la composition d'une application on hésitera pas.
Là encore, ça dépend de comment est structurée la BDD et quelles requêtes sont envoyées. Une fois de plus: Je suis entièrement d'accord qu'une API qui permet d'accéder aux données privées des autres utilisateurs est totalement inacceptable, quel que soit le niveau d'obfuscation par dessus. S'il suffit de modifier l'application client pour avoir des accès qu'on ne devrait pas avoir, la sécurité est totalement foireuse, même si c'est une application closed-source! Donc soit on a une BDD (ou un ensemble de tables, ou un schéma dans les BDDs comme PostgreSQL qui ont ce niveau de subdivision supplémentaire) par utilisateur, soit on travaille avec des vues.
Voir quelqu'un se connecter à une base de données à travers internet, ça titille vraiment. En plus, il y aura forcément un mot de passe visible en clair quelque part.
MariaDB et PostgreSQL permettent de te connecter en TLS (le protocole qui a remplacé SSL, souvent appelé incorrectement "SSL" par habitude), avec vérification du certificat. Donc non seulement aucun mot de passe n'est visible en clair, mais en plus un attaquant ne voit même pas que c'est un accès à une BDD (sauf éventuellement à travers le numéro de port si on utilise le port par défaut).
  • Tu peux probablement compter sur le fait que les protocoles de base de données ne soient pas sécurisés (certains le sont, c'est pas obligatoire, et chez ceux qui le font, c'est peut-être payant)
MariaDB ne coûte pas un sou, et si tu utilises les connecteurs du projet MariaDB plutôt que ceux du projet MySQL (donc MariaDB Connector/C, MariaDB Connector/J et/ou MariaDB Connector/ODBC), les bibliothèques client sont sous LGPL, donc utilisables gratuitement dans n'importe quelle application. Et TLS fait partie des fonctionnalités de base.

PostgreSQL est aussi entièrement gratuit (sous une licence style BSD) et propose aussi le TLS.
En dehors de l'aspect sécurité, tu peux pratiquement être certains que les protocoles d'accès aux bases de données ne sont pas optimisés pour la latence d'internet.
Ça oui, mais on s'en sort quand-même, et wrapper les accès sous encore une surcouche ne va pas les accélérer.
De fait, ce que "tu dois" faire (tu es libre, mais c'est vivement conseillé), c'est effectivement te créer une petite interface HTTP accessible sur le web. (Là tu peux te documenter un peu sur les API RESTful / JSON de manière plus générale que l'exemple succint donné dans ton lien. Mais j'ai conscience que ça va faire un peu lourd sad)L'idée c'est que le code que tu va héberger sur le serveur web ne sera accessible qu'à toi (puisque tu es le seul à pouvoir modifier son contenu), et même s'il contient les mots de passe d'accès à la base (si possible pas le mot de passe admin, quand même), personne ne pourra les voir.
Mais comme tu le dis après, il devra quand-même introduire des comptes et mots de passe pour les utilisateurs de l'application, sinon il n'y a aucune sécurité. Où est la différence?
Maintenant, on peut faire plus sécurisé… C'est de bon goût de ne pas laisser n'importe qui utiliser à ta petite API/base de données… Et si tu peux, c'est bien d'avoir un genre de gestion d'utilisateurs (encore via API du coup tongue) qui te permettre au niveau de ton API d'autoriser ou de refuser les requêtes. C'est même plutôt obligatoire si tu comptes aussi accéder à ta base en écriture.
C'est clair! Et du coup tu as réinventé l'authentification de ta BDD.

Bref, je résume: Une surcouche est nécessaire si et seulement si la structure de la BDD est telle qu'on ne peut pas permettre, à travers les contrôles d'accès natifs de la BDD, l'accès aux données de l'utilisateur sans permettre aussi l'accès aux données d'autres utilisateurs. Et si c'est le cas, les vues peuvent éventuellement contourner ce problème nativement dans la BDD, mais font évidemment que l'application doit être conçue pour (SELECT * FROM user31337_view; plutôt que SELECT * FROM everything WHERE user_id=31337;, parce que le compte user31337 ne doit avoir accès qu'à user31337_view et en aucun cas à la vraie table everything!). Une surcouche simple ne fait que réinventer les vues. Mais je concède que si le développeur est incapable de garantir la sécurité avec les mécanismes natifs de la BDD (que ce soit la faute de l'utilisation prévue, du développeur ou de la BDD, peu importe!), il vaut mieux faire une surcouche qui garantit la sécurité que proposer une API (accès direct à la BDD avec des permissions trop larges) facilement hackable à des fins malicieux!
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Ah oui, et un exemple concret de problème de sécurité courant dans les surcouches webapps qui n'existe pas dans un modèle de sécurité à base de comptes BDD et de vues SQL est l'injection SQL. (Dans le deuxième cas, l'utilisateur peut injecter ce qu'il veut, il ne pourra pas accéder à autre chose que sa vue. C'est tout le but de ce modèle de sécurité. Si ce n'est pas garanti, alors ce modèle de sécurité n'est pas implémenté correctement, comme déjà expliqué.)
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Sérieusement, Kevin, tu vis dans quel monde ?
Tu as déjà vu comment sont développées les applications dans le monde réel ? Vraiment personne de sensé dans le monde ne te conseillera jamais d'exposer ton serveur de base de données aux quatre vents sur internet.

Une API t'empêche pas de bien concevoir ton modèle de base de données (y.c gestion des comptes).
Une API t'oblige pas à coder comme un porc.
Une API n'a pas de compte root (une BDD si.)

Une API ça fait que personne n'accède directement à ta base, que personne ne manipule ton modèle de données physique, et que personne n'effectue d'opérations non prévues par ton modèle de données.
Y'a vraiment beaucoup de trucs qui s'expriment pas simplement/mal avec du simple SQL (tout au mieux ils s'expriment avec des procédures stockées, mais c'est assez illusoire de vouloir construire une application 100% avec ça), et en général on met cette logique dans la couche intermédiaire. S'il y a pas de logique supplémentaire c'est pas plus grave non plus.
Avec une API, ton serveur SQL est pas accessible de l'extérieur, donc pas faillible, et normalement ton serveur web non plus, sauf si tu te fais voler ton mdp chez l'hébergeur web.

Et tu crois vraiment qu'on peut pas faire d'injection SQL dans une application "client lourd" ? Vraiment ?

Je passe sur ton post précédent où tu "réponds" à côté de a plaque à chaque truc juste avant de trouver mes explications dans ta citation en dessous à chaque fois. À un moment j'avais même l'impression que tu avais inversé les blocs citations avec les réponses, j'ai même pas envie d'essayer d'y répondre neutral

Bref…
Le jour où tu fais une application Android, préviens moi, ça risque d'être rigolo.
avatarLe scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes
Euh une API, c'est pas non plus l'idéal, surtout s'il la développe lui-même. C'est le meilleur moyen pour avoir un trou de sécu encore plus gros... Bien sécuriser une BDD ça n'est pas impossible. Un compte root, ça se protège... et en dev d'entreprise (en tout cas dans le monde Oracle), on a autant d'utilisateurs Oracle que d'utilisateurs de l'application, et tous les droits sont donnés à ces utilisateurs de BDD en fonction de leurs droits effectifs...
avatar
Oui je suis d'accord, mais il ne faut pas oublier que souvent, en entreprise, ta base de données est accessible uniquement sur le réseau privé, et de ce fait "protégée". Ce n'est pas le même scénario que l'Internet mondial ^^ (Apres, la question en ./0 ne concerne peut-être qu'une utilisation sur réseau privé, mais j'ai quand même des doutes)
Pour ce qui est des API, je suis d'accord aussi qu'on peut faire des bêtises, maintenant, que ce soit PHP, Java ou .NET, tu as des framework qui t'aident à faire ça très rapidement pour les cas simples, et ça peut être très bien pour celui qui n'a pas trop le temps de se poser des questions smile
(Puis en réalité, blinder ta base de données, impliquant donc de pratiquement tout protéger par des procédures stockées, ça revient à faire un API, juste via un dérivé SQL ^^)

(Il y a un truc que j'ai oublié de mentionner tout à l'heure, c'est que les bases de données / drivers associés ont une gestion des connexion réseau bien différente d'un serveur HTTP (stateless) et ça peut peut-être coincer dans certains cas d'utilisation vis à vis du nombre de connexions TCP simultanées à la base, soit par le nombre d'utilisateurs, soit par le biais de connexions persistantes de ces utilisateurs. Habituellement, on utilise rarement un grand nombre de connexions, car normalement la base est accédee depuis un service instancié en petit nombre, et chaque instance fera du pooling de connexions pour soulager la base.)
avatarLe scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes
GoldenCrystal (./8) :
Et tu crois vraiment qu'on peut pas faire d'injection SQL dans une application "client lourd" ? Vraiment ?
Si les permissions de la BDD sont définis correctement, l'utilisateur ne pourra attaquer que lui-même, pas très intéressant. grin Une fois de plus, l'envoi direct de SQL n'est possible que si on peut envoyer n'importe quel SQL sans avoir accès aux données des autres utilisateurs. Alors que si c'est ta couche API qui fait en logiciel ce pour quoi les BDD prévoient les vues, et construit donc des requêtes de type SELECT * FROM everything WHERE user_id=31337 AND critere_machin="entrée utilisateur";, c'est une invitation pour les entrées de type " OR ""=".
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité
Bon, finalement, en pratique, les implémentations des vues n'ont pas le niveau de sécurité que le concept promettrait, comme l'explique la documentation de PostgreSQL:
http://www.postgresql.org/docs/9.3/static/rules-privileges.html
À noter aussi que security_barrier a l'effet collatéral de limiter la vue à la lecture seule. sick Et ça n'a pas l'air d'être mieux dans MySQL/MariaDB: cet aspect de sécurité n'est pas évoqué en détail dans la documentation de MySQL, mais l'équivalent de security_barrier (PostgreSQL) est ALGORITHM=TEMPTABLE qui empêche lui aussi l'utilisation en écriture. Et comme le décrit le lien sus-cité, même cette barrière de sécurité n'est pas parfaite non plus. sad
Bref, je comprends mieux maintenant le pourquoi de faire ça en une surcouche logicielle.

Mais bien sûr, le problème des vues ne se pose pas si les BDDs de chaque utilisateur sont séparées. C'est l'accès à une BDD commune qui doit être protégé.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité