Discussion:
PHP, SQL et securite
(trop ancien pour répondre)
geo75
2007-01-28 08:42:44 UTC
Permalink
Bonjour,

Je me posais une question sur la sécurité dans les scripts PHP,

Comment faire pour sécuriser les acces a la base de données ?

en effet meme avec post on arrive a lire les variables.

si j'envoi en post dans mon script

fiche_info.php?client=120&compte=10

comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client=121&compte=10
ou 122
etc...
Merci de votre aide
Olivier
2007-01-28 17:15:03 UTC
Permalink
Post by geo75
Je me posais une question sur la sécurité dans les scripts PHP,
Comment faire pour sécuriser les acces a la base de données ?
en effet meme avec post on arrive a lire les variables.
si j'envoi en post dans mon script
fiche_info.php?client=120&compte=10
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client=121&compte=10
ou 122
La question n'est pas de savoir ce que tu peux empêcher de faire par
le client mais de vérifier si ce qu'il fait est conforme à tes attentes.

Et comme ce genre de question revient de temps à autre, je me demande
toujours comment il est possible de faire confiance à une personne
virtuelle que l'on ne connaît pas, quand dans le même temps on aura une
confiance limité dans les déclarations de ses proches (famille, amis,
relation travail, etc.)...
Et lorsque soi-même on est pas tout à fait exempt de légers mensonges
envers les mêmes proches. Sauf les saints bien entendu.
--
Olivier
- Parce que sinon cela rompt le cours normal de la conversation.
- Pourquoi répond on après la question ?
<http://www.faqs.org/faqs/fr/usenet/repondre-sur-usenet/> merci.
Eric
2007-01-28 17:15:03 UTC
Permalink
Post by geo75
Comment faire pour sécuriser les acces a la base de données ?
en effet meme avec post on arrive a lire les variables.
si j'envoi en post dans mon script
fiche_info.php?client=120&compte=10
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client=121&compte=10
ou 122
etc...
Bonjour


Première question : pourquoi installer une telle sécurité ? Quelles seraient
les conséquences si qqun pouvait changer le chiffre ?

Si c'est pour un accès client, et que le client 120 n'a pas le droit
d'accéder à la page du client 121, alors il faut stocker ce chiffre dans la
session (en supposant que 1 session = 1 client), ou, si une session peut
correspondre à plusieurs clients, indiquer les correspondances session <-->
client, la session contiendrait ici le numéro du compte, et dans la base de
données, on associe compte et clients. Lorsque le serveur reçoit une requête
pour une page, il vérifie que l'utilisateur X a bien le droit de regarder la
page avec les paramètres fournis.


Deuxième solution, qui me semble très compliquée à mettre en oeuvre, pour
chaque page générée, tu tires des grands numéros au hasard (1564255873478,
556324543458, 485457864567), tu stoques d'une manière ou d'une autre que la
page 544534856486 aura comme paramètre {client=120;compte=10}. On aura alors
comme code :

<a href="index.php?page=456456465542">Modifier mes paramètres</a>
<a href="index.php?page=354684865486">Créer une nouvelle commande</a>

Plus le chiffre est grand, plus la probabilité qu'un "intrus" tombe sur une
page valide est faible !



A chaque réalisation que j'ai faite, une réflexion sur comment enregistrer
les droits de l'utilisateur (et une ou deux vérifications sur le contenu de
$_REQUEST) m'a toujours permis de surmonter les problèmes de changement de
paramètre.

Eric
Surfoo
2007-01-28 17:15:03 UTC
Permalink
Tu confonds POST et GET là.
L'exemple que tu montre c'est GET : les données sont envoyés via l'URL.
En POST les données sont envoyés « cachées » via une 2ème requête HTTP.

Donc dans ton cas il faut utiliser POST et non GET.
Post by geo75
Bonjour,
Je me posais une question sur la sécurité dans les scripts PHP,
Comment faire pour sécuriser les acces a la base de données ?
en effet meme avec post on arrive a lire les variables.
si j'envoi en post dans mon script
fiche_info.php?client=120&compte=10
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client=121&compte=10
ou 122
etc...
Merci de votre aide
Thierry Boudet
2007-01-28 20:51:20 UTC
Permalink
Post by Surfoo
En POST les données sont envoyés « cachées » via une 2ème requête HTTP.
Il n'y a pas de deuxième requète. Merci de de pas embrouiller
plus des choses qui ne sont déja pas simple pour les débutants.
--
Tsss, tss. La mondial a été un peu sacrifiée au niveau de la ligne, mais
il y a 4 places, il faut ce qu'il faut. La Dino est magnifique, elle est
d'une vulgarité italienne indépassable . C'est une très belle Ferrari,
dessinée pour des cons d'américains qui n'y ont rien compris.
Jean-Marc Molina
2007-02-13 20:45:18 UTC
Permalink
Post by Surfoo
Tu confonds POST et GET là.
L'exemple que tu montre c'est GET : les données sont envoyés via
l'URL. En POST les données sont envoyés « cachées » via une 2ème
requête HTTP.
Donc dans ton cas il faut utiliser POST et non GET.
À une époque pas si lointaine certains serveurs Web permettaient de traiter
les POST comme des GET puisqu'ici on aurait pu accéder aux numéros par de
simples accès aux variables $client et $compte. Souvenez les variables
globales... J'en ai froid dans le dos :)
amigaiste
2007-01-28 17:15:03 UTC
Permalink
Bonjour,

Il y a le Rewriting. Tu trouveras des infos sur google.

http://www.webrankinfo.com/analyses/autres/url-rewriting-debutants.php

a+++++
Post by geo75
Bonjour,
Je me posais une question sur la sécurité dans les scripts PHP,
Comment faire pour sécuriser les acces a la base de données ?
en effet meme avec post on arrive a lire les variables.
si j'envoi en post dans mon script
fiche_info.php?client=120&compte=10
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client=121&compte=10
ou 122
etc...
Merci de votre aide
obe
2007-01-28 17:15:03 UTC
Permalink
Salut,
Post by geo75
Bonjour,
Je me posais une question sur la sécurité dans les scripts PHP,
Comment faire pour sécuriser les acces a la base de données ?
en effet meme avec post on arrive a lire les variables.
Je n'ai pas compris le lien entre POST et le fait de lire les variables.
Post by geo75
si j'envoi en post dans mon script
fiche_info.php?client=120&compte=10
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client=121&compte=10
ou 122
etc...
Merci de votre aide
difficile de te répondre précisément sans exemple concret mais déjà je
pense que l'id d'un client doit plutôt se trouver dans une variable de
session. Idem pour tout autre "champ" sensible lié à cette id, ils ne
doivent pas apparaitre dans les urls ou les formulaires.

Il y a toujours la possibilité de serializer et crypter des données qui
apparaissent dans les urls ou les formulaires.

Il faut prévoir des mécanismes évitant le rejeu et "l'exploration" par
un utilisateur non authentifié.

Ce sont quelques pistes pour y voir plus clair (peut-être) ...

a+
dric-li
2007-01-28 17:15:03 UTC
Permalink
Post by geo75
Bonjour,
Je me posais une question sur la sécurité dans les scripts PHP,
Comment faire pour sécuriser les acces a la base de données ?
en effet meme avec post on arrive a lire les variables.
si j'envoi en post dans mon script
fiche_info.php?client=120&compte=10
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client=121&compte=10
ou 122
etc...
Merci de votre aide
Bonjour

Une règle d'or : ne jamais faire totalement confiance aux paramètres passés
en GET ou POST. Il faut toujours vérifier la cohérence de ces paramètres,
par exemple en vérifiant si l'utilisateur courant est bien habilité à
consulter les données en rapport avec ces paramètres...
--
+----------------------------------------------------+
Linux user #347847 registered on http://counter.li.org
+----------http://www.mandrivalinux.com -------------+
geo75
2007-01-28 20:51:20 UTC
Permalink
Merci beaucoup pour vos nombreuses réponses. Il est vrai que je n'ai
pas pensé beaucoup à sécuriser les scripts.
Il faut que j'y travaille.
John GALLET
2007-01-28 20:51:20 UTC
Permalink
Post by geo75
Comment faire pour sécuriser les acces a la base de données ?
Ca dépend desquels on parle. Apparement tu parles de vérifier qu'on n'a
pas accès à des données confidentielles dont on n'est pas propriétaire
(confidentialité/propriété).
Post by geo75
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client=121&compte=10
ou 122
Personne ne peut l'empêcher, par définition même du protocole http. Et ce,
comme tu le fais fort justement remarquer, qu'on soit en get, en post, ou
même dans un cookie : on se fout de la méthode de transmission de la
variable car son danger est lié à son contenu.

En revanche, avec une session (ou en fait simplement avec un login/pass,
de manière générale n'importe quel moyen d'authentification), tu peux
vérifier à qui tu as affaire, et en stockant dans le schéma la liste des
utilisateurs autorisés à accéder aux données, tu recoupes et tu ajoutes la
clause WHERE qui va bien pour que même si un attaquant tripatouille les
variables, il ne puisse accéder qu'aux données auxquellees il est
explicitement autorisé à accéder.

a++;
JG
Jean-Marc Molina
2007-02-13 20:45:18 UTC
Permalink
Post by John GALLET
En revanche, avec une session (ou en fait simplement avec un
login/pass, de manière générale n'importe quel moyen
d'authentification), tu peux vérifier à qui tu as affaire, et en
stockant dans le schéma la liste des utilisateurs autorisés à accéder
aux données, tu recoupes et tu ajoutes la clause WHERE qui va bien
pour que même si un attaquant tripatouille les variables, il ne
puisse accéder qu'aux données auxquellees il est explicitement
autorisé à accéder.
En effet et le contrôle doit surtout être effectué en aval et surtout pas en
amont. Par exemple certains se contentent de vérifier l'info au niveau de
JavaScript ! Dans le cas d'un bouton "Supprimer" c'est au niveau du "DELETE"
qu'il faut vérifier qu'un utilisateur est bien autorisé à supprimer un
enregistrement de la base. Il ne suffit pas par exemple de cacher le bouton
"Supprimer" aux utilisateurs non autorisés. Je parle en connaissance de
cause car à mes débuts je me contentais de sécuriser l'interface utilisateur
!
Jean-Marc Molina
2007-02-14 22:00:19 UTC
Permalink
Post by geo75
Je me posais une question sur la sécurité dans les scripts PHP,
Comment faire pour sécuriser les acces a la base de données ?
en effet meme avec post on arrive a lire les variables.
si j'envoi en post dans mon script
fiche_info.php?client=120&compte=10
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client=121&compte=10
ou 122
En plus de l'authentification il faut aussi valider les paramètres qui sont
passés à un script via l'URL. Ici bien vérifier que "client" et "compte"
sont des numériques, à l'aide de la fonction "is_numeric" par exemple. Pour
d'autres types de données il faut passer par les autres fonctions "is_" ou
valider une valeur contre une expression régulière ("/[0-9]+/"...).

Cette technique de validation des paramètres d'une URL s'applique aussi aux
fonctions, aux données en provenance d'un formulaire (passées en POST ou en
GET peu importe)... J'insiste sur le fait que toutes les données doivent
être contrôlées et validées, aucune exception en matière de sécurité. L'un
des risques pour la BDD c'est de se prendre de belles injections SQL à base
de DELETE et autres abominations. Un autre classique est d'inclure un script
nommé à partir de la valeur d'un paramètre : <?php include
("client_$client.php") ?>... Les idées ne manquent pas :|

D'après ton exemple si il s'agit de développer un espace sécurisé pour des
clients, je te recommande plutôt d'opter pour une solution pro (script pro,
composant d'authentification d'un CMS, forum comme phpBB...). La sécurité
n'est pas à prendre à la légère, surtout quand on est pas expert dans le
domaine. Vérifier aussi que ton hébergeur supporte SSL pour que les données
transitant entre les clients et les serveurs sont cryptées. Mais que cela ne
t'empêche pas d'en apprendre plus sur le sujet en testant tout ça dans ton
coin.

Continuer la lecture sur narkive:
Loading...