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?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer simplement par fiche_info.php?client1&compte ou 122 etc... Merci de votre aide
obe
Salut,
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.
si j'envoi en post dans mon script
fiche_info.php?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer simplement par fiche_info.php?client1&compte 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+
Salut,
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.
si j'envoi en post dans mon script
fiche_info.php?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client1&compte
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) ...
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.
si j'envoi en post dans mon script
fiche_info.php?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer simplement par fiche_info.php?client1&compte 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
geo75 wrote:
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?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer simplement par fiche_info.php?client1&compte 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 wrote:
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?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client1&compte
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 -------------+
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?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer simplement par fiche_info.php?client1&compte 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 -------------+
Olivier
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?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer simplement par fiche_info.php?client1&compte 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.
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?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client1&compte
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.
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?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer simplement par fiche_info.php?client1&compte 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
"geo75" a écrit dans le message de news:
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?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer simplement par fiche_info.php?client1&compte 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 {client0;compte}. On aura alors comme code :
<a href="index.php?pageE6456465542">Modifier mes paramètres</a> <a href="index.php?page54684865486">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
"geo75" <sdefay2004@yahoo.fr> a écrit dans le message de news:
1169937734.421803.142130@j27g2000cwj.googlegroups.com...
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?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client1&compte
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 {client0;compte}. On aura alors
comme code :
<a href="index.php?pageE6456465542">Modifier mes paramètres</a>
<a href="index.php?page54684865486">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.
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?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer simplement par fiche_info.php?client1&compte 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 {client0;compte}. On aura alors comme code :
<a href="index.php?pageE6456465542">Modifier mes paramètres</a> <a href="index.php?page54684865486">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
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.
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?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer simplement par fiche_info.php?client1&compte ou 122 etc... Merci de votre aide
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.
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?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client1&compte
ou 122
etc...
Merci de votre aide
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.
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?client0&compte
comment puis je empecher celui ci puisse par exemple remplacer simplement par fiche_info.php?client1&compte ou 122 etc... Merci de votre aide
John GALLET
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é).
comment puis je empecher celui ci puisse par exemple remplacer simplement par fiche_info.php?client1&compte 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
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é).
comment puis je empecher celui ci puisse par exemple remplacer
simplement par fiche_info.php?client1&compte
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.
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é).
comment puis je empecher celui ci puisse par exemple remplacer simplement par fiche_info.php?client1&compte 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
Thierry Boudet
On 2007-01-28, Surfoo wrote:
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.
On 2007-01-28, Surfoo <surfooo@gmail.com> wrote:
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.
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.
geo75
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.
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.
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.
Jean-Marc Molina
John GALLET wrote:
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 !
John GALLET wrote:
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
!
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 !
