Discussion :

[LFC]

Bonjour,
le logiciel sqlmap permet de tester les vulnérabilités postgresql.
Or, le résutlat d'un check sqlmap montre le nom du schéma de la DB.
Comment peut on cacher le nom du schéma/db à sqlmap ?
Merci.

[SQLpro]

Vous confondez la notion de schéma SQL et la notion de bases de données. Ces deux concepts n'ont rien à voir l'un avec l'autre !

Lisez l'article que j'ai écrit à ce sujet :
https://blog.developpez.com/sqlpro/p...des_schema_sql


A +

[LFC]

Bonjour,

j'ai effectivement réalisé un raccourci entre ces 2 notions et je me suis empressé de lire l'article.

Disons que le logiciel sqlmap dise :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
available databases [1]:
[*] public

Est-ce que c'est considéré comme une faille de sécurité ou pas ? Si oui, j'ai suivi les différents conseils que postgresql donne dans sa section "sécurisation", mais je ne vois pas de quelle manière corriger cela. Les nombreux articles sur le Net ne me donnent pas d'indices non plus.

Une idée ?

Merci.

[SQLpro]

Les bases étant cloisonnées dans PG, un utilisateur d'une base a ne voit pas et ne peut pas atteindre une base B sauf si un DBlink est créé avec des permissions sp"cifiques.

Pour les schémas SQL, vous pouvez donner des privilèges individuellement aux schemas.

Pour le schéma "public" qui est une des pires imbécilité en matière de faille de sécurité, il dvaudrait mieux ne jamais rien créer dans ce schéma et même prévoir un déclencheur DDL qui supprime tout ce qui y est créé !
https://wiki.postgresql.org/wiki/A_G...ur_Search_Path


A +

[LFC]

J'ai bien compris qu'il en fallait pas laisser en vie le "public" qui est créé par défaut, mais je disais - pour ne pas citer le vrai nom de la db que j'utilise - que si sqlmap arrive à lire le nom de la db, est-ce que c'est une faille et on peut y rémédier en cachant cela ?
sqlmap est un logiciel gratuit sur le net, donc quand il teste des failles de sécurité sur n'importe quel site web, il n'y a pas de notion de droit sur un user ou pas.

Si je prends un exemple tout autre.

Disons que je lance sqlmap sur le site developpez.net pour tenter de trouver quel est le type de DB qu'ils utilisent, je lancerai :
sqlmap -u https://www.developpez.net/forums/anologin3.php etc.

Si sqlmap après de nombreux tests affiche que le site utilise une DB postgresql et le nom de la DB de cette forme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
available databases [1]:
[*] developpeznet_database

que pourrait faire ce site pour cacher cette information ?

J'espère que c'est plus clair maintenant.

Merci.

[Sve@r]

Bonjour

... donc quand il teste des failles de sécurité sur n'importe quel site web, il n'y a pas de notion de droit sur un user ou pas.

Si bien sûr. Car le site internet se connecte fatalement à la bdd à un moment ou un autre. Et il passe pour ça par un user dédié à cette connexion. Et ce user a fatalement des droits de connexion à la bdd et d'exécuter ne serait-ce qu'un simple select current_database()).

que pourrait faire ce site pour cacher cette information ?

Déjà si tu arrives, que ce soit avec sqlmap ou simplement par un psql classique, à trouver le nom de la bdd d'un site web, c'est que ce site est déjà bien malade et plus trouée qu'un gruyère et dans ce cas, cette info n'a alors plus d'importance (comme un type qui perd un sac d'or et qui aurait envie de protéger les quelques euros de son portefeuille). Parce que dans les sites bien faits, la bdd se trouve derrière le serveur web. Le serveur peut accéder à la bdd via un réseau interne mais toi tu ne le peux pas. C'est le minimum requis pour pouvoir se dire "sécurisé". Plus les trucs de base qui sont de mettre bien évidemment un mot de passe au user postgres et bien évidemment ne pas mettre de connexion "trust" dans le fichier pg_hba.conf. On peut aussi changer le port par défaut (5432). Déjà là tu as un truc un peu sérieux. Si en plus le site web se trouve sur un serveur Linux dans une partition bien à lui et que la partition est montée en read-only là tu peux commencer à te sentir bien à l'aise.

Ensuite vient la sécurisation de ta base elle-même. Déjà tu lui mets un user d'admin à son nom, mais sans droit login (exemple pour un bdd "toto" tu crées le user "toto_dba" via un create role toto_dba nosuperuser nocreatedb nocreaterole noinherit nologin). Ainsi juste son existence permet de créer ensuite la bdd à son nom avec create database toto with owner=toto_dba puis faire ensuite un set role "toto_dba" pour que toute la suite de la création de la bdd se fasse sous le compte "toto_dba". Ainsi tous les schémas, toutes les tables, tous les objets de la bdd lui appartiennent.
Ensuite plus tard tu pourras créer des users réels cette fois, qui auront eux le droit d'administrer la bdd "toto". Exemple create user "LFC" nosuperuser nocreatedb nocreaterole inherit login; grant "toto_dba" to "LFC". Ainsi le user "LFC" pourra administrer la bdd "toto" déjà sans avoir besoin du mot de passe de postgres et surtout il ne pourra pas administrer la bdd "titi".
Et ensuite tu crées de la même façon un user dédié à utiliser la base (exemple create role toto_user nosuperuser nocreatedb nocreaterole noinherit nologin). Puis pour chaque schéma, chaque table que tu crées, tu commences par faire un revoke all privileges on table truc from public puis un grant select, insert, update, delete on table truc to toto_user. Ainsi seul toto_user (enfin ses héritiers) pourront accéder au contenu de la bdd. Et enfin ne te reste qu'à créer les vrais users (associés eux à des personnes réelles) en les faisant hériter de "toto_user" (même méthode que pour "toto_dba"). Ainsi cela leur permettra de se connecter à la bdd et travailler dedans.
A partir de là, m'étonnerait que sqlmap puisse trouver quoi que ce soit de consistant et même si le nom de la bdd ressortait quelque part on ne pourrait pas en faire grand chose.

Concernant le schéma public mentionné par SQLpro je sentais que c'était pas terrible mais sans trop savoir pourquoi donc je ne l'utilise à la base jamais. Déjà mes bdd contiennent toujours différents domaines chacun associé à un schéma dédié donc c'est aussi pour des raisons d'organisation que je n'utilisais pas public. Et aussi question sécurité j'aimais bien car quand le schéma n'est pas "public" il doit être explicitement mentionné dans le nom de la table lors des requêtes. Donc tu te connectes à une de mes bdd, tu fais un \dt et déjà premier fuck. Ok les schémas d'une bdd ça se trouve mais quand-même ça fait plaisir.
Et en allant voir la page qu'il cite avec l'exemple où on peut créer sa propre fonction lower() qui remplace l'officielle ok je vois mieux et je suis content d'avoir fait ce choix.