Attaque croisée en php

Citation:

---

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

---

Ben de toute façon une authentification est reproductible dans un script en quelques minutes.
Les jetons pareil, ça ne sert à rien ici.
Le plus efficace reste àmha le captcha à chaque soumission ou l'analyse du comportement de l'utilisateur authentifié, mais est-ce que ça en vaut bien la peine ?

un captcha a chaque page, tu es fou !!
Quand je suis sur facebook par exemple et que je remplie un formulaire je n'ai pas besoin de remplir de captcha.
Aucun bout de code à proposé ???
Un début de solution fiable..

Citation:

---

Envoyé par Fredo02

un captcha a chaque page, tu es fou !!

---

Je n'ai pas dis ça ;)

Citation:

---

Aucun bout de code à proposé ???
Un début de solution fiable..

---

Je ne sais toujours pas dans quel contexte donc non.
Et puis le gros a déjà été dit.

bah je récap.
J'ai un site avec une authentification basé sur mysql.
Une fois connecté, une variable de session est crée et stocke un objet membre.

au moment ou je poste les valeurs en base, j'aimerai m'assurer que celui qui poste n'est pas un pirate.

un petit bout de code stp.

Merci pour les réponses.

Citation:

---

Envoyé par Fredo02

au moment ou je poste les valeurs en base, j'aimerai m'assurer que celui qui poste n'est pas un pirate.

---

C'est quoi un pirate pour toi ?

roooo tu cherches la petite bête.
Pour moi le pirate c'est le mec qui va tenté d'utiliser mes pages php pour injecter des données sans passé par les contrôles de validation coté client.

Si un simple test de session suffit pourquoi pas.
je veux juste un exemple pour voir si c'est aussi simple que je le pense.

Bon, je me lance.

Code:

---

1 2 3 4 5 6 7 8 9

<?php session_start(); if(empty($_SESSION['connect'])) { header('Location: <a href="http://www.site.fr/login.php&#39;);" target="_blank">http://www.site.fr/login.php');</a> exit(); } ?>

---

Est ce que ça suffit pour être sur que la page ne sera pas appelée depuis un autre domaine ou encore d'une façon détournée ?
Quelles sont les limites de cette solution ? si il y en a, comment corriger ?

Citation:

---

Envoyé par Fredo02

Pour moi le pirate c'est le mec qui va tenté d'utiliser mes pages php pour injecter des données

---

OK

Citation:

---

sans passé par les contrôles de validation coté client.

---

Pour ça il suffit de désactiver JavaScript du navigateur :))

Citation:

---

Si un simple test de session suffit pourquoi pas.

---

Non, ce n'est pas suffisant.

Citation:

---

Envoyé par Fredo02

Bon, je me lance.

Code:

---

1 2 3 4 5 6 7 8

<?php session_start(); if(empty($_SESSION['connect'])) { header('Location: <a href="http://www.site.fr/login.php&#39;);" target="_blank">http://www.site.fr/login.php');</a> exit(); } ?>

---

Est ce que ça suffit pour être sur que la page ne sera pas appelée depuis un autre domaine ou encore d'une façon détournée ?
Quelles sont les limites de cette solution ? si il y en a, comment corriger ?

---

C'est suffisant si le "pirate" n'est pas authentifié.

EDIT : et qu'il ne peut pas voler la session d'un utilisateur authentifié.

dans ce cas comment le "pirate" va faire pour voler la session ou encore faire exécuté du code ?

Si il se connecte et qu'il nous fait un petit shell qui appelle x fois la page, je ne peux pas faire grand chose a part gérer un quota d'injection en base pour limiter les dégâts.

Je veux la solution ultime !!
Ça me fait peur ces réponses, j'ai l'impression que tous les sites du monde entier sont vulnérables.

Pour info, il est possible de récupérer les sessions dans une iframe.
---------------
Après une mise à jour d'Internet Explorer vers IE 7, les variables de session n'étaient plus transmises à la page provenant d'un autre site Web contenue dans un <IFRAME></IFRAME> (les variables de la session étaient détruites).

L'astuce consiste à envoyer une en-tête HTTP spécifique (en-tête de stratégie compacte P3P / Microsoft) :

Code:

---

1 2 3

<?php // avant session_start() header('P3P: CP="CAO PSA OUR"');

---

Citation:

---

dans ce cas comment le "pirate" va faire pour voler la session

---

Sniffe les trames réseau pour récupérer le PHPSESSID ou man-in-the-middle (ex. proxy sournois), etc.

Citation:

---

ou encore faire exécuté du code ?

---

Facile quand on a récupéré le PHPSESSID. Suffit d'adresser la requête HTTP quivabien au serveur.

Citation:

---

Si il se connecte et qu'il nous fait un petit shell qui appelle x fois la page, je ne peux pas faire grand chose a part gérer un quota d'injection en base pour limiter les dégâts.

---

Exact, d'où le :

Citation:

---

Certains forums empêchent de poster un nouveau message trop rapidement.

---

Citation:

---

Envoyé par Fredo02

dans ce cas comment le "pirate" va faire pour voler la session ou encore faire exécuté du code ?

Si il se connecte et qu'il nous fait un petit shell qui appelle x fois la page, je ne peux pas faire grand chose a part gérer un quota d'injection en base pour limiter les dégâts.

Je veux la solution ultime !!
Ça me fait peur ces réponses, j'ai l'impression que tous les sites du monde entier sont vulnérables.

---

Les sessions sont suffisantes pour que les variables de session ne puissent être vues et utilisées que par un seul utilisateur pour un usage courant cf ce lien Comme mentionné il faut passer l'identifiant de session dans un cookie et donc activer session.use_only_cookies. Après cela le seul piratage possible de l'identifiant de session est de pirater le réseau. La solution ultime est de passer par une connexion SSL (souvent utilisée uniquement lors du règlement banquaire).

A part cela on peut faire exécuter - dans certaines conditions pour les visiteurs non avertis - un script par quelqu'un déjà identifié en lui faisant cliquer sur un lien pendant qu'il est enregistré. Pour se prémunir de ce genre d'attaques il faut utiliser la méthode post pour le traitement des formulaires et autres actions de communication avec le serveur pour les données sensibles. On peut aussi utiliser un système de jetons si l'on doit utiliser la méthode get, ou pour blinder un peu plus la méthode post pour les paranos.

Concernant le déni de service c'est un problème de gestion de serveur et non de code php.

Cela dit tu peux bien utiliser une connexion SSL et avoir des trous de sécurités dans ton code. A toi de faire attention aux données sensibles, genres scripts inclus dont le nom de fichier passerait par des données visiteurs, téléchargement de fichier sans précautions, requêtes non protégées etc.

Citation:

---

Envoyé par Fredo02

un captcha a chaque page, tu es fou !!
Quand je suis sur facebook par exemple et que je remplie un formulaire je n'ai pas besoin de remplir de captcha.
Aucun bout de code à proposé ???
Un début de solution fiable..

---

Facebook c'est la même chose que pour toi , tu peux très bie nfaire un script qui se connecte sur facebook.com et qui va poster sur ton mur toutes les 10 sec.

Après tu peux mettre en place des filtres qui empèche ce genre de comportement mais il n'y a pas de solution magique. Formulaire sur internet = accessible.
Tu peux rendre plus ou moins difficile l'exploitation de ce formulaire mais pas l’empêcher.

Citation:

---

Pour moi le pirate c'est le mec qui va tenté d'utiliser mes pages php pour injecter des données sans passé par les contrôles de validation coté client.

---

La vérification coté client ne doit être qu'un élément de confort pour l'utilisateur , en aucun cas tu peux te reposer dessus. Toute vérification des données doit être fait coté serveur.

Citation:

---

Envoyé par grunk

La vérification coté client ne doit être qu'un élément de confort pour l'utilisateur , en aucun cas tu peux te reposer dessus. Toute vérification des données doit être fait coté serveur.

---

Tout est dit !

vs inquiétés pas pour çà. c'est aussi vérifié coté serveur.
Je ne suis pas kamikaze.

En fait c'est le test de session sur chaque page qui me gène.
Je suis étonné qu'il n'y est pas de solution telles que les membership provider pour le .Net.

On pourrait alors spécifier quelles pages ont besoin d'une authentification.
Mais bon, si je voulais être feignant, il fallait pas choisir le php.

Merci pour vos réponses.

Citation:

---

Envoyé par Fredo02

En fait c'est le test de session sur chaque page qui me gène.
Je suis étonné qu'il n'y est pas de solution telles que les membership provider pour le .Net.

On pourrait alors spécifier quelles pages ont besoin d'une authentification.
Mais bon, si je voulais être feignant, il fallait pas choisir le php.

---

Bon nombre de framework PHP le font.
C'est juste que le .NET n'est pas un langage, c'est une technologie. On ne peut pas vraiment faire une réelle comparaison entre les deux. ;)

Alors je connais bien le sujet, et je suis tout a fait d'accord que l'on ne peut pas comparer.
Seulement je trouve que le .Net rend un peu feignant et nous fais passé à coté de pleins de fondamentaux.

Je précise également que le .net n'est pas seulement une technologie mais plusieurs à la fois.

Pour résumer un peu ce qui est à ta disposition.

- Empêcher l'utilisation du formulaire par tous le monde : identification (session)
- S'assurer que les données reçues viennent bien du formulaire affiché sur l'écran de l'utilisateur : token
- Empêcher ou diminuer l'apparition de bot : captcha

Les sessions ne peuvent transiter d'un domaine à un autre surtout si ces deux domaine ne sont pas sur le même serveur.

Si tu veux sécuriser au maximum ton site l'emploi d'un framework pourrait être bénéfique surtout si PHP n'est pas ton domaine de prédilection.

Citation:

---

Envoyé par Fredo02

...
En fait c'est le test de session sur chaque page qui me gène.
Je suis étonné qu'il n'y est pas de solution telles que les membership provider pour le .Net.

On pourrait alors spécifier quelles pages ont besoin d'une authentification.
...

---

J'ai du mal à comprendre ton interrogation. Si besoin de test d'authentification sur une page -> test de session d'authentification, si pas besoin -> pas de test de session d'authentification. Tu trouves cela compliqué ?

Si tu veux spécifier quelles pages sont concernées dans un seul endroit, chacune de tes pages peut faire un require sur un script commun qui décidera (en fonction par exemple de l'url en cours comparée à un tableau que tu auras défini) si la session d'authentification est requise ou pas.

Ou éventuellement comme déjà dit plus haut tu peux utiliser un framework qui fera cela à ta place, cela dit l'apprentissage d'un framework nécessite des connaissances minimum et aussi pas mal de temps.