J'évalue la sécurité d'un portail Web pour un client et j'ai trouvé une vulnérabilité.
C'est le code PHP:
echo(file_get_contents("template/data/" $_GET['id']));
J'ai pu lire avec succès ../../../index.php, config.php etc.
Mais je veux juste pouvoir prouver que ce bogue est plus critique que la lecture des configs. J'ai lu l'utilisateur/pass MySQL, mais je ne peux pas me connecter depuis son écoute sur localhost uniquement. Tous les autres codes que j'ai lus ne conduisaient à rien. Donc, fondamentalement, je n'ai obtenu que du code source qui n'était pas un secret.
Je ne peux pas faire de filtrage php car il contient "template/data /" au début de la chaîne.
Que peut-on faire d'autre avec ce morceau de code vulnérable? Des idées?
La base de données MySQL est-elle sur la même machine? Si oui, pouvez-vous simplement extraire les fichiers de base de données et reconstruire la base de données sur votre machine?
Comme d'autres l'ont dit, vous pouvez extraire/etc/passwd qui contient beaucoup d'informations sur la disposition des utilisateurs. Si vous pouvez accéder à/etc/shadow, vous pouvez essayer de cracker les mots de passe hors ligne.
Si l'application Web dispose d'un portail de connexion, essayez les informations d'identification mysql ainsi que "admin", "root" etc. avec le mot de passe.
Le code source ou les fichiers de configuration contiennent-ils d'autres informations d'identification d'accès/clés API? Le certificat SSL du site est-il lisible - si c'est le cas, vous pouvez connecter Man In the Middle?
Vous pouvez également extraire les détails de/proc/version,/etc/issue etc. et des versions de serveur Web pour rechercher d'autres vulnérabilités connues.
Enfin, la source est-elle censée être publique? Sinon, le code source est souvent considéré comme précieux. Et vous pouvez inspecter cela pour d'autres vulnérabilités.
La réponse d'Hector contient de bons exemples, mais j'aimerais souligner un autre point très important:
Ce n'est pas une petite vulnérabilité
Vous semblez avoir l'impression que si "tout" vous pouvez faire est de lire des fichiers arbitraires sur leur système, alors la vulnérabilité n'est pas vraiment une vulnérabilité. Je dirais exactement le contraire. Vous devez comprendre que la sécurité est mieux approchée du point de vue de la défense en profondeur. Il peut être pratiquement impossible d'avoir un système sans vulnérabilité, donc l'objectif est d'avoir autant de couches de défense que possible dans autant de domaines que possible, de sorte que si un acteur malveillant trouve une faiblesse dans une zone, des défenses dans tout le système les empêchera de causer de réels dommages. De nombreuses violations du monde réel se produisent, non pas parce qu'il y avait une vulnérabilité dont quelqu'un a profité, mais parce qu'il y avait une vulnérabilité qui leur permettait de profiter d'une autre vulnérabilité, qui leur permettait de faire autre chose, jusqu'à ce qu'ils trouvent quelque chose vraiment = dangereux.
Cette petite vulnérabilité donne aux acteurs malveillants un accès complet en lecture à votre système. Cela est encore aggravé par le fait qu'il s'agissait d'une erreur de sécurité assez évidente. Si l'entreprise en question avait des développeurs bien formés et procédait à des révisions régulières du code, il est (IMO) très peu probable qu'un tel code parvienne à un système de production. L'importance de ce fait est qu'il suggère que ce ne sera pas la seule vulnérabilité de sécurité présente. Le fait que vous ayez maintenant un moyen d'afficher directement le code source du système signifie que trouver d'autres vulnérabilités de sécurité est sensiblement plus facile. Peut-être que le jeu est terminé. Si j'étais un acteur malveillant et j'ai trouvé cela, je le ferais:
Ce n'est pas un problème de sécurité isolé. De telles choses n'existent jamais dans la pratique.
Beaucoup de bonnes informations dans les autres réponses qui incluent beaucoup de pourraient se produire réalité et devraient être prises au sérieux.
Pas sûr de votre configuration d'hébergement, mais disons que vous êtes sur un serveur avec d'autres comptes et que la fonction est utilisée pour obtenir le contenu de /etc/passwd
qui inclut des lignes comme celle-ci pour les utilisateurs du système:
username:x:123:654::/home/username:/usr/local/cpanel/bin/noshell
username:x:123:654::/home/username:/usr/local/cpanel/bin/noshell
username:x:123:654::/home/username:/usr/local/cpanel/bin/noshell
etc...
Vous pouvez alors pour chaque passe de nom d'utilisateur:
/home/username/public_html/wp-config.php
Et finissez avec le fichier de configuration de chaque site wp. Ce n'est qu'un exemple ... en fin de compte, vous devriez faire de votre mieux pour sécuriser les choses plus haut que le code - comme une autre couche.
Que devrait se produire si un chemin local comme/etc/passwd est fourni à la fonction:
<br />
<b>Warning</b>: file_get_contents(): open_basedir restriction in effect. File(/etc/passwd) is not within the allowed path(s): (/home/uservalue/public_html) in <b>/home/uservalue/public_html/test.php</b> on line <b>2</b><br />
<br />
<b>Warning</b>: file_get_contents(/etc/passwd): failed to open stream: Operation not permitted in <b>/home/uservalue/public_html/test.php</b> on line <b>2</b><br />
"restriction open_basedir en vigueur."