Vous n'êtes pas identifié(e).

#1 09/04/2010 17:48:42

jacqueline
Membre

Securite de connection avec PHP

Bonjour je suis  debutante avec PostgreSQL.


J'ai lu   la doc, mais une question me turlupine,  avant d'aller plus loin dans la doc et la pratique.

Il semblerait que le seul mode de connection possible avec PHP  a pg comme dans MySQL :

<?php

$dbconn = pg_connect("host=localhost dbname=publishing user=www password=foo")
    or die('Connexion impossible : ' . pg_last_error()); 
 

A moins que quelque chose m'ait echappe..


Pas top au niveau securite

Dans certaines conditions il est possible  de recuperer les identifiants de connection  a la base de donnees., et le mdp etant en clair..

Possible de les recuperer depuis un site voisin mal protege ( ou mal intentionne )  sur un hebergement mutualise.


Existe t-il   un moyen  de  proteger un peu  plus cet acces a la base de donnees dans du php ?

Dernière modification par jacqueline (10/04/2010 10:33:47)

Hors ligne

#2 10/04/2010 10:33:02

gleu
Administrateur

Re : Securite de connection avec PHP

Pour cela, encore faudrait-il qu'ils puissent récupérer le script PHP...

Cela étant dit, si vous ne voulez pas indiquer le mot de passe dans le script PHP, vous pouvez aussi passer par un fichier .pgpass. Ce dernier se trouvant dans le répertoire personnel de l'utilisateur apache, personne ne peut le récupérer à moins d'une connexion SSH au serveur.


Guillaume.

Hors ligne

#3 10/04/2010 10:39:16

jacqueline
Membre

Re : Securite de connection avec PHP

Merci beaucoup pour   .pgpass 

Je vais regarder ca de plus pres.

Hors ligne

#4 10/04/2010 13:33:24

jacqueline
Membre

Re : Securite de connection avec PHP

J'ai une autre question , simple a formuler ?

( J'ai  vu la page d'accueil de votre site  Dalibo )

Est ce que vous , experts des bases de donnees, considerez que  permettre l'accces a toute une base de donnees depuis internet  avec  un site web en php est une solution sure ?

Compte tenu de tous les types d'attaques recenses.

Il existe des protections contre les injections SQL qui ont l'air d'etre difficiles a mettre au point, car  on voit de nombreux CMS publier des  corrcetifs , suite a la decouverte de nouvelles vulnerabilites pour ce seul chapitre du piratage.

C'est exactement la meme chose pour les injections de scripts pirates ou backdoor, lorsqu on recense toutes les possibilites.

Voir  Orange et la SNCF se faire pirater leurs comptes clients, alors que ce sont des pros, me fait douter de ces securites des sites Web.

J'ai le sentiment que les  web devloppers , sont toujours a courir derriere les pirates.

Alors qu il me semble, qu'on peut plus securiser l'acces a une base de donnees distante avec  une  connection en SSL, avec les echanges de cles et  les firewalls.

Pourquoi cette question ?

A la maniere des banques et des casinos,  qui ne gardent pas  de grosses sommes d'argent  a leurs guichets, pour se proteger des hold-ups, ou en limiter les consequences,  il me semble qu on peut faire qqchose d'analogue pour les donnees confidentielles , comme les comptes clients ou les donnees relatives aux commandes   d'un site de e-commerce. 

C'est a dire : des qu un client a saisie toutes  ses donnees  personnelles  dans   une table de la base de donnees du site web . 

Les transferer automatiquement et sytematiquement  par une connection SSL sur un serveur de base de donnees distant, et effacer l'enregistrement dans la table  du site web, une fois le transfert effectue..

Ainsi en cas d'intrusion sur le site web public, quelle qu en soit l'origine ou la cause, il n'y a pas de donnees  confidentielles a voler dans la table client du site web.

Bien entendu ce transfert serait fait au niveau  base de donnees , avec un autre user que celui d apache pour echapper  au champ d'Apache  en chroot, afin de le rendre invisible et inaccessible depuis le web en se connectant au site public .

Avec mes modestes moyens je reflechis a d'autres solutions que celles qui nous sont proposees dans les CMS.


Techniquement  c'est plus complique, mais ca me semble plus sur.

Penalisant  en terme de vitesse , d'accord ! 

Mais pas pour la navigation  et  limite a quelques operations des clients.  La plupart des sites de e-commerce n'ont pas tous un traffic si  intense, les gros sites de vente en ligne ont d'autres moyens.

Je pense  qu il est temps de passer a autre chose ,  pour les  site de e-commerce  , qu un site web realise a partir d'un CMS,  sur un hergement mutualise, chez un hebergeur a prix casse.

Les CMS de e-commerce sont a peine plus securises qu'un CMS  de blog ou de forum, alors qu un piratage a beaucoup plus de consequences et que les sites de e-commerce sont la cible  principale des pirates.

Aux infos de France 2 , il y a quelques mois, j'ai vu un pirate repenti  faire sa demo :   trois minutes pour ramasser tous les comptes clients avec les coordonnees bancaires, sur  trois sites de e-commerce selectionnes avec Google. 

Une fois l'etonnement passe, ca n'a pas l'air d'alerter  les developpeurs concernes.   



En esperant que mon souci soit partage.


Merci de votre avis d'expert et de votre patience pour avoir lu mon post..

Dernière modification par jacqueline (10/04/2010 13:53:19)

Hors ligne

#5 10/04/2010 18:43:00

gleu
Administrateur

Re : Securite de connection avec PHP

Est ce que vous , experts des bases de donnees, considerez que  permettre l'accces a toute une base de donnees depuis internet  avec  un site web en php est une solution sure ?

Si c'est y accéder via une application web, oui, il est possible de développer quelque chose qui soit sécurisé. Certainement pas sécurisé contre tout, ceci étant impossible à faire. Un pirate déterminé arrivera toujours à trouver un moyen. Le plus simple étant de demander aux gens leur mot de passe (c'est étonnant à quel point certains le donnent facilement).

Il existe des protections contre les injections SQL qui ont l'air d'etre difficiles a mettre au point, car  on voit de nombreux CMS publier des  corrcetifs , suite a la decouverte de nouvelles vulnerabilites pour ce seul chapitre du piratage.

En PHP, il existe une fonction qui permet d'éviter les injections SQL avec PostgreSQL : pg_escape_string(). En utilisant cette fonction sur chaque entrée utilisateur, ça permet d'éviter de gros soucis.

J'ai le sentiment que les  web devloppers , sont toujours a courir derriere les pirates.

Oui. Comme les développeurs d'antivirus sont toujours à courir derrière les créateurs de virus, comme les administrateurs systèmes sont toujours à courir derrière les pirates, comme les concepteurs de verrous ou de coffre-fort sont toujours à courir derrière les voleurs, etc, etc.


Guillaume.

Hors ligne

#6 11/04/2010 13:50:35

jacqueline
Membre

Re : Securite de connection avec PHP

gleu a écrit :

En PHP, il existe une fonction qui permet d'éviter les injections SQL avec PostgreSQL : pg_escape_string(). En utilisant cette fonction sur chaque entrée utilisateur, ça permet d'éviter de gros soucis.

Merci pour   pg_escape_string(). ca m'inspire plus confiance que ce que j'ai vu, et je n'oublierais pas.

Dans les boites ,   souvent les gens donnent leurs mots de passe, pour des raisons  pratiques, dans certaines situations, mais  je ne pense pas qu un  patron de site  de e-commerce le divulgue aussi facilement.

Pire  avec  un certain CMS il n'est pas besoin de  mdp, pour enlever les backups de la base de donnees,  stockes dans un sous repertoire de l'admin, technique connue publiee sur des sites de securite, faisant appel a Google,  mais on trouve encore cette fonctionnalite..

J'aurais aime avoir votre avis sur mon idee de base deportee..

Tant pis , je continue sur cette idee.

Lorsqu il n'y a plus de donnees  confidentielles a voler sur le site public, ca couvre tous les cas de figure du piratage,  pour le vol de donnees, meme ceux qui ne sont pas encore connus, ou la  toujours possible defalllance d'une protection..

L'autre interet :   au lieu d'avoir un site multilingue, pour des raisons de  referencement  et  une autre raison  plus obscure dont m' a parle la proprietaire ( et amie ) de cette petite boite qui vend  dans plusieurs pays :  a l'experience   il est preferable d'avoir un site par langue avec le nom de domaine correspondant ..


Aussi rapatrier les  donnees des commandes et les donnees clients sur un serveur centralise,  simplifie la gestion multisites..

On peut envisager de l'etendre egalement a l'ajout de nouveaux produits, ou a la suppression.

La possibilite de mettre les images  produits dans   PostgreSQL  me semble  interressante  a ce niveau..

Car l'upload avec le php dans un repertoire images du site  oblige a laisser le droit d'ecriture dans ce repertoire, et constitue en soi  une vulnerabilite :

de nombreux sites en ont ete vicitimes, quels que soient les moyens employes pour arriver a  injecter  des scripts pirates ou des virus dans ce  repertoire

( celui qui a  fait le plus de victimes etant la consequence indirecte d' une  vulnerabilite de filezilla, a laquelle personne n'avait songe )

Une autre  idee  aussi,  pour completer la securite des sites distants ,  une fois  installes  puisqu il n'y aurait  plus d'elements variables, sauf dans la base de donnees, dont l'acces limite  au seul serveur centralise est  plus facile a blinder :

avec  des serveurs    BSD, est   de verrouiller totalement   les repertoires du site  avec les chflags, et de faire fonctionner le serveur en niveau de securite 2.

Il est egalement possible de cacher ces ports  de communication entre bases de donnees  aux intrus, contrairement aux ports http et https auquels les visiteurs et clients doivent avoir acces..

J'ai vraiment apprecie cette idee ( chflags et secure-level ) de  BSD , qui n'a pas d'equivalent  sous Linux..  A reserver a ce genre d'applications , sinon qu' est ce qu on s'ennuye avec un serveur verrouille , puisqu on ne peut plus rien modifier, mais c'est le but.. Principalement  concue pour la protection contre les rootkits de plus en plus difficiles a detecter..   

Faute d'avoir trouve des exemples de base de donnees qui communiquent entre elles ( pourtant ca doit exister ) , je pensais avoir recours a  des scripts perl, tournant sous le user pgsql, mais  bien sur  pas en CGI dans un repertoire htttp.

Il sera toujours temps de revoir cette partie pour l'ameliorer,  mais  je pars avec  ce principe de base de donnees centralisee., communiquant avec les bases satellites, qui ne rend plus obligatoire  d'avoir un admin sur les sites web, un autre point faible..

Encore hier soir , avec la demo d'un nouveau  systeme de e-commerce , voir encore une fois  avec l'admin tout ce qui  traine comme donnees  confidentielles  sur un serveur distant , puisque tres justement on ne peut pas garantir a 100 % la securite d'un site web ouvert a tout l'internet, et ce ne sont pas les exemples qui manquent,  me conforte dans cette idee d'essayer autre chose.

Hors ligne

#7 11/04/2010 23:27:50

gleu
Administrateur

Re : Securite de connection avec PHP

J'aurais aime avoir votre avis sur mon idee de base deportee.

Que je ne vois pas trop ce que ça change au problème. Lorsque le client revient, il ne veut pas avoir à resaisir ses infos, donc il faudra bien un moyen pour que le site aille récupérer les infos, ce qui laisse un moyen pour les pirates.

Lorsqu il n'y a plus de donnees  confidentielles a voler sur le site public, ca couvre tous les cas de figure du piratage,  pour le vol de donnees, meme ceux qui ne sont pas encore connus, ou la  toujours possible defalllance d'une protection..

Non, il reste le phishing, moins complexe à mettre en place et certainement très efficace.


Guillaume.

Hors ligne

#8 12/04/2010 16:29:07

jacqueline
Membre

Re : Securite de connection avec PHP

gleu a écrit :

J'aurais aime avoir votre avis sur mon idee de base deportee.

Que je ne vois pas trop ce que ça change au problème. Lorsque le client revient, il ne veut pas avoir à resaisir ses infos, donc il faudra bien un moyen pour que le site aille récupérer les infos, ce qui laisse un moyen pour les pirates..

Pour les e-commerce , il faut une authentification, et une gestion de sessions  plus serrees que sur un forum., et un controle de coherence des donnees saisies a l'identification. ( que  fait de toute facons manuellement le commercant ). Il s'agit d'eliminer toutes les  inscriptions bidons et les risques de fausses commandes..

Cela existe  dans certains  CMS sous forme d'extension ou de plugin ,  plus ou moins bien integres  car  ce n'etait pas prevu au depart..

Le but de ce systeme de base deportee est prevu au depart pour eviter le vol  de toute une table de la base de donees en une seule requete, puisque c'est un script inaccessible depuis le web , qui fera la requete, pour le client, qui n'aura pas acces a la table distante. ( il n 'a pas les privileges pour y acceder et ne verra ni le nom de user , ni le mot de passe, ni le nom de la table, ni  l'IP du serveur distant, ni les cles ssl.)...

Bien sur la demande de voir  les donees du compte , ou les suivis de commande ,  d'un client normal doivent passer  :

du php a une table tampon , qui sera lue par le script , qui  fera la demande a la place du client..

Mais le script peut faire un certain nombre de controles, avant d 'interroger le serveur distant  et avant de  servir les donnees demandees dans la table tampon qui sera relue par le php,  de maniere a empecher qu un "client pirate identifie"  puisse demander autre chose que ce qui le concerne..

La requete  ne se fera pas simplement  avec un identifiant de client.. et surtout avant de  servir les donnees demnadees, il faut s'assurer qu on les donne a la bonne personne qui auraitt pu changer entre temps..

il  est aussi possible d'y ajouter des cles aleatoires, pour personnaliser  le script  "opensource", et rendre impossible l'acces a  une personne qui aurait le script   sous le nez pour essayer de pirater le systeme.. ( une idee inspiree  de phpMyadmin..)


Mais tout cela n'etait pas ma preoccupation immediate,  merite d'etre testee, peut evoluer en fonction de ma decouverte de PostgreSQL..   




gleu a écrit :

Lorsqu il n'y a plus de donnees  confidentielles a voler sur le site public, ca couvre tous les cas de figure du piratage,  pour le vol de donnees, meme ceux qui ne sont pas encore connus, ou la  toujours possible defalllance d'une protection..

Non, il reste le phishing, moins complexe à mettre en place et certainement très efficace.

Une autre realite a prendre en compte est que les clients ( a les voir faire parfois chez eux , ou  comme je l'ai vu dans une mediatheque : abandonner le poste  sans se deconnecter , sans effacer ses traces et en laissant des documents dans les dossiers.. ) ne sont pas tous au fait des problemes de securite. Quand a leur demander de sceuriser leur PC ou d'utiliser un autre OS... 

C'est leur probleme , mais  avec un site de vente en ligne, ca pose toujours des problemes lorsqu un client s'est fait arnaquer.

En cas de doute , je prefere avertir le client, que   de le laisser se faire pieger ou pirater.

Pour ce qui est  de : pishing, vol de sessions, vols de mdp et detournement de connection..

Il   existe diverses techniques , plus ou moins fiables et plus ou moins contraignantes pour les eviter.

(  Mais on sort un peu du domaine des bases de donnees...? ).

Je ne me serais pas lancee dans cette idee de base de donnees deportee , en oubliant le reste.

La securite informatique est un sujet qui me passionne depuis longtemps, et je pense etre bien informee la dessus .. C'est pour moi plus interressant et plus utile qu une partie d'echecs..


le bon  mot cle pour avoir les meilleures infos etant  crimeware..

Depuis quelques mois, j'ai teste pas mal d'outils. Je les regarde fonctionner,   et je ne doute pas une seconde que les pirates les utilsent pour  balayer le net a la recherche  des serveurs  les moins bien proteges ou pour faire l'inventaire des lieux..

Il  suffit de laisser  un serveur ouvert sur le net et d 'utiliser un sniffer pour voir tous ces bots qui balayent le net de facon systematique avant de passer a l'offensive..     


Google a trouve une idee simple et efficace,  pour detecter les detournements de connection qui pourrait  etre adaptee pour detecter egalement    les vols d'identifiants et mots de passe  lorsqu on a pas le traffic de Google...

Elle est dans un rapport assez complet sur la securite des navigateurs ou on parle aussi de clickjacking..

Mais il y a d'autres possibilites , inspirees par le fonctionnement de ces outils en regardant defiler les paquets sur le sniffer.. ca peut aider a la configuration de l'IDS et   il me semble assez facile de les leurrer,  ou de les empoisonner , au lieu de les laisser poursuivre leur  travail en restant passive.
.

Devant les diificultes qu il ya a se proteger de tout, et qu on ne maitrise rien  des PC des clients,  je reste convaincue que mon idee de base separee apporte un PLUS  au niveau securite, car de toutes facons  je serais confrontee aux memes problemes   de securite, en gardant les donnees confidentielles sur le site, avec en prime le risque de me les faire voler..

Et   ce serait certainement un plus grand nombre de clients qui se feraient pirater leur compte,  ou pourraient se faire cambrioler ou plus simplement se faire spammer..

Hier soir, j'ai trouve un  exemple   de script perl , relativement simple,  pour  resoudre un problemes du meme genre avec des bases de donnees distantes, ou il n'etait  pas necessaire d'utiliser les gros outils specialises..


J'ai adore  cet exemple , d'une boite pro, pour demontrer qu elle etait capable d'etudier des solutions  simples, sur mesure au lieu de proposer une autre usine a gaz pour resoudre un petit probleme...

   
De toutes facons , ce systeme de base deportee est pour moi  interressant a etudier, a essayer.. .et il  faudrait plus que quelques doutes des uns ou des autres pour me demotiver ;  et ca ne me branche pas du tout de refaire quelque chose, dont je connais deja tous les defauts.

Une bonne motivation pour l'apprentissage de PostgreSQL et perl par la meme occasion...

Je ne suis pas du tout motivee pour apprendre qq chose, si je n'en ai pas l'utilite.. 

Voila , j'ai ce qu 'il faut pour attaquer

Merci

Hors ligne

Pied de page des forums