Discussion :

[Fredo02]

Bonjour,

je me pose une question.
J'ai un site développé en php couplé avec Mysql.
Ce site propose de la saisie d'information via des formulaires en POST.
Les valeurs postées sont récupérées dans un fichier php qui se charge de mettre les infos en base.

Ma question est la suivante :
Est ce que si quelqu'un reproduit mon formulaire sur un autre domaine en utilisant ma page php il peut injecter des données dans ma base.

Si oui, existe t'il un moyen de savoir si le formulaire posté provient bien du domaine courant ?

Merci

[Séb.]

Si oui, existe t'il un moyen de savoir si le formulaire posté provient bien du domaine courant ?

$_SERVER['HTTP_REFERER'] te donne la page précédente, tu peux vérifier si elle correspond à la page censée soumettre le form.
C'est un début mais c'est facilement contournable car ce n'est qu'une en-tête HTTP renseignée par le client.

Donne-nous plus d'infos sur ce que tu veux faire précisément et dans quel contexte.

[transgohan]

Et surtout que la moitié des navigateurs ne renseignent pas cette entête. :/

[Fredo02]

Autre solution ?
Il doit surement y'en avoir... c'est une faille béante pour toutes les applications sinon..

[stealth35]

Autre solution ?
Il doit surement y'en avoir... c'est une faille béante pour toutes les applications sinon..

utilise un captcha, ou une identification

[Séb.]

Autre solution ?

Quel est le problème précisément ?

Il doit surement y'en avoir... c'est une faille béante pour toutes les applications sinon..

Certains forums empêchent de poster un nouveau message trop rapidement.
Certains sites utilisent des captcha pour s'assurer qu'il y a bien qqu'un et pas un robot-floodeur derrière la requête.

[Séb.]

Et surtout que la moitié des navigateurs ne renseignent pas cette entête. :/

Je viens de tester avec Firefox, Chrome et IE, ça passe sous XP.

[grunk]

Le problème du referer c'est que le mec qui prend le temps d'attaquer tes scripts à distance prendra soin de remplir les entête http de manière adéquate , donc tu ne peux pas te reposer la dessus.

La sécurité la plus simple et très certainement la plus efficace reste de mettre en place un token (jeton en bon français).

Pour schématiser :

- Ton formulaire génère un jeton unique (chaine de caractère aléatoire par exemple). Ce jeton est stocké en session et dans un input hidden.

- Au moment de la soumission du formulaire le token est donc envoyé avec ton formulaire (et fait donc partie des prérequis à la validation des données)

- Sur ton script de réception des données tu compare simplement le token reçu et le token en session ainsi que son TTL (histoire de pas avoir des token illimité dans le temps). Comme il est unique si il ne correspond pas c'est que les données reçue ne proviennent pas du formulaire qui à généré le token.

Un petit exemple simple : http://blog.oroger.fr/2009/07/31/se-...s-csrf-en-php/

[stealth35]

Le problème du referer c'est que le mec qui prend le temps d'attaquer tes scripts à distance prendra soin de remplir les entête http de manière adéquate , donc tu ne peux pas te reposer la dessus.

La sécurité la plus simple et très certainement la plus efficace reste de mettre en place un token (jeton en bon français).

Pour schématiser :

- Ton formulaire génère un jeton unique (chaine de caractère aléatoire par exemple). Ce jeton est stocké en session et dans un input hidden.

- Au moment de la soumission du formulaire le token est donc envoyé avec ton formulaire (et fait donc partie des prérequis à la validation des données)

- Sur ton script de réception des données tu compare simplement le token reçu et le token en session ainsi que son TTL (histoire de pas avoir des token illimité dans le temps). Comme il est unique si il ne correspond pas c'est que les données reçue ne proviennent pas du formulaire qui à généré le token.

Un petit exemple simple : http://blog.oroger.fr/2009/07/31/se-...s-csrf-en-php/

tu peux bypass le token via cURL puisque qu'il aura une session, les tokens servent surtout pour être sur que c'est le même utilisateur qui soumet la requête