Attaque croisée en php

[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]

Envoyé par Fredo02

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.]

Envoyé par Fredo02

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.]

Envoyé par transgohan

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]

Envoyé par 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/

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

[grunk]

Envoyé par stealth35

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

Tu pars du principe qu'il soumet le formulaire du site via cURL , l'op parlait d'un formulaire sur un autre site (en local par exemple) qui viendrait attaquer ses scripts de traitement.

Mais dans le cas d'une attaque des formulaire du site directement via cURL y'a pas de solution miracle puisque même l'identification pourra êter bypassée

[stealth35]

Envoyé par grunk

Tu pars du principe qu'il soumet le formulaire du site via cURL , l'op parlait d'un formulaire sur un autre site (en local par exemple) qui viendrait attaquer ses scripts de traitement.

Mais dans le cas d'une attaque des formulaire du site directement via cURL y'a pas de solution miracle puisque même l'identification pourra êter bypassée

en reproduction statique oui le token est la solution la plus simple
en dynamique y'a le captcha

(si on parle de bot bien-sur)

[Fredo02]

C'est quand même hallucinant qu'il n'y est aucune solution ultime à ce problème.
Tous les sites sont vulnérables si toutes les solutions peuvent être bypassées.

Un expert en sécurité à la rescousse ??

[stealth35]

Envoyé par Fredo02

C'est quand même hallucinant qu'il n'y est aucune solution ultime à ce problème.
Tous les sites sont vulnérables si toutes les solutions peuvent être bypassées.

Un expert en sécurité à la rescousse ??

token + captcha, y'a peu de chance, après faut se mettre dans la tête que la sécurité ultime n'existe pas.

[grunk]

Envoyé par Fredo02

C'est quand même hallucinant qu'il n'y est aucune solution ultime à ce problème.
Tous les sites sont vulnérables si toutes les solutions peuvent être bypassées.

Un expert en sécurité à la rescousse ??

A partir du moment ou tu peux émuler le comportement d'un navigateur (envoi et réception de requête http) tu peux bien faire ce que tu veux.
Après comme le dit Stealth35 tu peux limiter les robots en imposant une action humaine. Action qui reste encore une fois pas 100% robuste puisque des robots un peu évolué savent faire de l'OCR sur un captcha.

Un captcha + un token + une identification et tu es à peu près sur de pas être embêté.

Edit --
Grilled

[Fredo02]

Imaginons le pirate qui prépare son coup.
Il se fait une petite page avec un include ou une iframe qui pointe vers mon fichier php.
Il se prépare une variable de session en allant chercher le name du input contenant la clé.
A ce stade tout est prêt.


Maintenant il va sur mon formulaire en utilisant mon application, récupère la valeur du token en regardant le code source html.
Il se dépêche de retourner sur sa page destinée au hack, met la valeur récupérée en session et injecte des données.

Il passe le token et le ttl. Facile

[grunk]

Envoyé par Fredo02

Imaginons le pirate qui prépare son coup.
Il se fait une petite page avec un include ou une iframe qui pointe vers mon fichier php.
Il se prépare une variable de session en allant chercher le name du input contenant la clé.
A ce stade tout est prêt.


Maintenant il va sur mon formulaire en utilisant mon application, récupère la valeur du token en regardant le code source html.
Il se dépêche de retourner sur sa page destinée au hack, met la valeur récupérée en session et injecte des données.

Il passe le token et le ttl. Facile

Il irait sur ton site directement ça serait vachement plus simple entre nous ^^.
L'important dans la soumission de formulaire , c'est de s'assurer que la personne qui affiche le formulaire est bien la même que celle qui envoi les données et que les soumission ne se font pas à la chaine par des robots.

[stealth35]

mais oui si y'a pas d'authentification, c'est normal que tout le monde puisse soumettre ton formulaire, et si tout le monde peut le faire je vois pas en quoi c'est un problème de le faire d'un autre site

[Fredo02]

il y a une authentification sur mon site.
En gros ce que vous semblez dire c'est un truc du genre..

if(isset($_SESSION['IsConnect'])) {
Mon Script
}
else {
Dégage sale pirate !!!!
}

Si je créer une variable de session IsConnect sur un autre site et que je fais un include ou une iframe vers ma page php, adieu le système d'authentification

[grunk]

Une session est liée à un domaine. Si tu créer une session sur xxx.com même si tu fait une iframe elle ne sera pas valable sur yyy.org.

Pour une sécurité optimale tu peux même gérer tes session via ta base de données : voir tuto

[westdigit]

Non, la session est propre au serveur.

Donc une session créé sur un serveur a ne sera pas lu par un serveur b.

Donc peut importe que la session sur le serveur a ait les mêmes variables que la session sur le serveur b, elle ne vont pas interférer entre elles.