Vous n'êtes pas identifié(e).
Pages : 1
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
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
Merci beaucoup pour .pgpass
Je vais regarder ca de plus pres.
Hors ligne
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
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
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
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
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..
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
Pages : 1
