03-10-2020, 04:55 PM
Salut,
j'ai la flemme perso de monter le projet en local, mais niveau sécu, je pense que vu le projet, tu ne pourras pas rendre ça "safe" dès l'instant où la personne est autorisée à faire une action d'édition. Autrement dit, il y aura des path traversal (possibilité d'uploader un fichier avec n'importe quel nom n'importe où, moyennant l'usage de ../ dans les noms), des RCE (Remote Command Execution) en chargeant des fausses images qui sont en fait du PHP, ou des XSS un peu partout (en chargeant des HTML en place/embarqués dans les images).
Donc IMO, la seule défense à avoir, c'est d'avoir 2 rôles: visiteur en lecture seule, et administrateur avec les pleins pouvoirs.
Pour authentifier les deux, je vois que tu t'es reposé sur un mot de passe en session? Bon, je ne suis pas convaincu (il aurait suffit de faire un boolean $_SESSION['isOK'] et de le tester en tête de chaque page d'edition). En revanche, le fichier de login https://github.com/Stern-Hillpocken/foto.../login.php pose soucis, car le mot de passe mis en session est directement celui envoyé par POST. Et ca, ca veut dire que si tu veux changer le mdp (qui est "mdp" x) ), il faudra éditer TOUS les fichiers.
Pour éviter cela, il suffit de faire (en gros):
Il y a des "open redirect" un peu partout (aka des redirections qui utilisent une URL donnée par le client). Cela permet, par exemple, de rediriger la personne vers un site de phishing après son login.
L'exemple-type étant htt ps ://victime.com/login?redirect=evil.com/login et la page de evil . com va afficher un beau "mot de passe invalide, veuillez recommencer". Quand l'utilisateur va sur le lien, le site victime demande à ce qu'il se loggue. L'utilisateur met son vrai mot de passe, et se log sur le site-victime. Celui-ci à cause du open redirect, renvoie l'utilisateur vers le site evil . com qui lui dit [et c'est faux] "mot de passe pas valide". L'utilisateur se dit "crotte, j'ai mal tappé?" il recommence, rentre son mdp, et le site evil . com enregistre ce mot de passe puis renvoie l'utilisateur vers victime . com et le mdp a été volé
Pour éviter cela, il faudrait valider toutes les redirections du genre, et obliger, par exemple, à ce qu'elles soient de la forme "~\./[a-z0-9-]{5,30}\.php$~" ce qui interdit une redirection vers un site externe.
Voilà, c'est un retour rapide ^^
j'ai la flemme perso de monter le projet en local, mais niveau sécu, je pense que vu le projet, tu ne pourras pas rendre ça "safe" dès l'instant où la personne est autorisée à faire une action d'édition. Autrement dit, il y aura des path traversal (possibilité d'uploader un fichier avec n'importe quel nom n'importe où, moyennant l'usage de ../ dans les noms), des RCE (Remote Command Execution) en chargeant des fausses images qui sont en fait du PHP, ou des XSS un peu partout (en chargeant des HTML en place/embarqués dans les images).
Donc IMO, la seule défense à avoir, c'est d'avoir 2 rôles: visiteur en lecture seule, et administrateur avec les pleins pouvoirs.
Pour authentifier les deux, je vois que tu t'es reposé sur un mot de passe en session? Bon, je ne suis pas convaincu (il aurait suffit de faire un boolean $_SESSION['isOK'] et de le tester en tête de chaque page d'edition). En revanche, le fichier de login https://github.com/Stern-Hillpocken/foto.../login.php pose soucis, car le mot de passe mis en session est directement celui envoyé par POST. Et ca, ca veut dire que si tu veux changer le mdp (qui est "mdp" x) ), il faudra éditer TOUS les fichiers.
Pour éviter cela, il suffit de faire (en gros):
Code :
if ($_POST['motdepasse'] !== "le mot de passe compliqué qu'on ne change qu'ici") {
echo "prout";
exit;
}
session_start();
$_SESSION['isOk ou mot de passe'] = true ou "mdp" parce que osef, le but est juste de dire que la session de cette personne est OK;
Il y a des "open redirect" un peu partout (aka des redirections qui utilisent une URL donnée par le client). Cela permet, par exemple, de rediriger la personne vers un site de phishing après son login.
L'exemple-type étant htt ps ://victime.com/login?redirect=evil.com/login et la page de evil . com va afficher un beau "mot de passe invalide, veuillez recommencer". Quand l'utilisateur va sur le lien, le site victime demande à ce qu'il se loggue. L'utilisateur met son vrai mot de passe, et se log sur le site-victime. Celui-ci à cause du open redirect, renvoie l'utilisateur vers le site evil . com qui lui dit [et c'est faux] "mot de passe pas valide". L'utilisateur se dit "crotte, j'ai mal tappé?" il recommence, rentre son mdp, et le site evil . com enregistre ce mot de passe puis renvoie l'utilisateur vers victime . com et le mdp a été volé
Pour éviter cela, il faudrait valider toutes les redirections du genre, et obliger, par exemple, à ce qu'elles soient de la forme "~\./[a-z0-9-]{5,30}\.php$~" ce qui interdit une redirection vers un site externe.
Voilà, c'est un retour rapide ^^