J'ai récemment reçu un courrier de phishing d'une qualité inhabituellement mauvaise; "Veuillez vous connecter immédiatement sous le lien suivant, car nous sommes votre banque, vous savez" -ish. Le lien pointe vers une URL peu convaincante avec .php
à la fin.
Je me demandais pourquoi ils pourraient utiliser un script PHP au lieu de simuler simplement l'apparence de la page donnée et de soumettre les données saisies à un formulaire.
Je ne veux pas vraiment cliquer sur le lien pour le découvrir, mais j'aimerais savoir ce que ce fichier PHP est sur le point de faire. Existe-t-il un moyen de télécharger le script, tel comme vous pourriez le faire avec le JavaScript côté client?
Ou ne suis-je pas en mesure d'accéder au fichier PHP, car il est exécuté par le serveur?
Existe-t-il d'autres moyens d'analyser ce fichier et son comportement sans aucun danger?
Si le serveur est configuré correctement, vous ne pouvez pas télécharger un fichier PHP. Il sera exécuté lorsqu'il sera appelé via le serveur Web. La seule façon de voir ce qu'il fait est d'accéder au serveur via SSH ou FTP ou une autre méthode.
En effet, PHP est un langage côté serveur, toutes les actions sont effectuées sur le serveur, puis le résultat est envoyé à votre navigateur (qui est client côté).
Si vous avez peur de jouer avec votre système, vous pouvez utiliser Virtualbox avec un Ubuntu VM et ouvrir la page à partir de là. Si vous prenez un instantané du VM = après l'installation et avant de faire des choses dangereuses, vous pouvez plus tard revenir à cet instantané et annuler tout ce que le script aurait pu faire à la machine virtuelle.
Comme d'autres l'ont dit, le fichier PHP est exécuté côté serveur, sauf si le serveur est si mal configuré qu'il servira simplement la source.
Si vous souhaitez examiner ce qui est envoyé à votre client sans qu'il puisse faire quoi que ce soit de fâcheux, utilisez un éditeur de texte comme le Bloc-notes pour ouvrir l'URL. Autrement dit, utilisez File → Open
mais ouvrez l'URL plutôt qu'un vrai fichier.
Le serveur interprétera la demande et enverra ce qu'il enverrait normalement à un navigateur. Votre éditeur de texte le recevra, mais tout ce qu'un éditeur de texte peut faire est de l'afficher si vous le souhaitez. Il ne s'approchera jamais d'un navigateur ou d'un autre moteur de rendu à exécuter.
Le .php
le fichier est exécuté côté serveur donc il n'y a malheureusement aucun moyen d'obtenir le code source. Ce que vous pouvez essayer cependant, c'est de manipuler l'URL en espérant que l'administrateur système a fait une erreur.
Lorsqu'un utilisateur visite http://www.example.com/index.php, le serveur Web génère la réponse HTML par /usr/bin/php
exécution du index.php
fichier de /var/www/html
.
Les serveurs Web sont généralement configurés pour exécuter .php
fichiers uniquement, donc .jpg
ou tout autre type de fichier est servi normalement.
Si un administrateur système oublieux a fait une copie du .php
fichier à des fins de sauvegarde cependant, vous pourrez peut-être récupérer la copie sans être exécuté par /usr/bin/php
Donc, si l'administrateur système a fait une copie en tant que /var/www/html/index.php.bak
, vous pouvez télécharger son code source en visitant http://www.example.com/index.php.bak avec votre navigateur.
La recherche de ces fichiers restants est une tâche fastidieuse, donc vous voudrez peut-être jeter un œil aux outils de fuzzing d'URL automatisés.
Enfin, je recommande d'utiliser curl
pour faire ces expériences, car il n'exécutera pas JavaScript ou Flash sur votre machine.
Non , vous ne pouvez pas, car PHP est exécuté sur le serveur. Fin.
Il y a une manière si le serveur contient un exploit LFI: https: //www.owasp .org/index.php/Testing_for_Local_File_Inclusion .
Cependant, si le serveur est correctement configuré une fois, il ne devrait pas être possible de télécharger les fichiers PHP.
J'ai récemment eu le plaisir de corriger cela dans un projet dont j'ai hérité, d'où la raison pour laquelle je le connais. On pourrait télécharger directement les scripts PHP en donnant le nom du script souhaité sur le $_GET[]
qui compterait.
À vrai dire, vous devriez avoir de la chance qu'il y ait un exploit possible et vous devez également comprendre la façon dont le système de fichiers du serveur est structuré (c'est-à-dire quel est le chemin relatif du script qui vous intéresse par rapport à le script contenant la vulnérabilité LFI) Donc, si vous prévoyez d'explorer le serveur, utilisez un sandbox/VM. Vous aurez peut-être de la chance si le serveur est en effet mal configuré comme le suggère le commentaire de Gustavo Rodrigues.
Vous ne pouvez pas via HTTP car
A) Le code PHP écrit dans le fichier est supprimé du fichier par le serveur http avant d'être envoyé au client http
Ainsi, un formulaire HTML pourrait référencer blah.php qui contient un extrait php, du code entouré de balises php, qui vérifie si le mot de passe soumis = 1234 mais si vous deviez wget blah.php vous ne verrez pas ce code. (même si le serveur web supportant php vous a permis d'obtenir directement blah.php, sans vous rediriger pour recevoir un autre fichier .. ce n'est pas vraiment le blah.php sur le serveur que vous obtenez). C'est blah.php traité par le serveur avec le code php supprimé et remplacé par tout ce que le php produit. Ou avec n'importe quel code côté client (html/javascript), le code php déterminé doit être affiché.
et
B) le module php du serveur HTTP exécutera tout php et produira le fichier résultant à envoyer au client.
Soit dit en passant, techniquement, un fichier HTML sur un serveur peut contenir PHP. Donc ce n'est pas comme PHP sont plus dangereux que les fichiers HTML. PHP fait le traitement du serveur et génère ensuite d'autres choses côté client que l'on peut trouver dans un fichier HTML) comme HTML ou javascript côté client.