INTERDIRE LE PASSAGE DE FONCTION DANS UNE URL
bono62
-
3 mai 2013 à 23:25
cs_christophedlr Messages postés 267 Date d'inscription samedi 3 janvier 2004 Statut Membre Dernière intervention 23 août 2023 - 30 mai 2016 à 14:58
cs_christophedlr Messages postés 267 Date d'inscription samedi 3 janvier 2004 Statut Membre Dernière intervention 23 août 2023 - 30 mai 2016 à 14:58
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/55117-interdire-le-passage-de-fonction-dans-une-url
https://codes-sources.commentcamarche.net/source/55117-interdire-le-passage-de-fonction-dans-une-url
30 mai 2016 à 14:58
D'ailleurs en URL Rewriting, on utilise forcément un système de routing, soit un moteur soit un truc bricolé à la main. Soit le système travaille donc avec les $_GET comme je l'ai fait sur mon moteur, soit avec d'autres trucs comme le fait Symfony Routing.
L'exécution d'un code mis dans le $_GET ne se fait que si le paramètre en question est appelé, ainsi prend un code qui vérifie jamais la présence d'un $_GET, il est déjà sécurisé puisque le paramètre n'est jamais vérifié et aucun traitement donc de réaliser dessus.
En URL Rewriting, on peut déjà bloquer les GET et même les POST il me semble (a vérifier), en revanche il est con de s'en priver ; si les grands moteurs comme celui de Symfony permettent de travailler avec en plus de l'URL Rewriting c'est pas pour rien.
C'est au code derrière qui traite les données, à vérifier que c'est quelque d'attendus. Si on te fait par exemple : http://test.com/index.php?module=http://test.com/jecassetout.php et que tu fais un include du paramètre module sans avoir rien vérifier derrière, tu as un soucis de sécurité. Si maintenant le paramètre est vérifié, authentifier et rejeter au besoin (donc non traité et donc non exécuté), tu as déjà la sécurité attendue sans un code supplémentaire qui ne fait pas son office et te prive d'une fonctionnalité intéressante.
30 mai 2016 à 14:50
Quand tu ajoutes un paramètre à l'URL et appui sur entrer comme tu le dis, la page est rechargée puisqu'une nouvelle requête est envoyée au serveur. Donc quand tu dis et je cite :
"il est évident que tout le code se trouvant après s'exécute et que la page est chargé et envoyer dans le navigateur, le but ces que une fois la page chargé, il est impossible d'entrée de nouveaux paramètres dans la barre d'adresse en plus de l'url et de faire enter pour tenté une attaque, l'internaute sera alors redirigé vers l'adresse choisie, ces but de se code et sa marche, mais comme tu l'Einstein du php forcément tout le monde a tort sauf toi"
C'est ton post numéroté 20 d'ailleurs. Non, tu te trompes car comme tu envoi une nouvelle requête au serveur, forcément le code est de nouveau exécuté mais cette fois avec les infos données en URL que ton code est sensé empêché.
Le seul moyen est de rajouter un exit() là où tu as détecté et mis ton meta, cela stoppe alors l'exécution du code, et le mauvais code ne sera jamais exécuté.
C'est ce que Emilie à essayer de t'expliquer.
19 mai 2015 à 20:18
@ tchaOo°
23 janv. 2015 à 02:15
1:
Pourquoi en ligne 2 ?
Cette opération ne sert à rien, ,
Il suffit d'écrire en ligne 4 et in peut se passer de la ligne 2 et le code est déjà plus propre.
2:
Ce code ne fonctionnera pas dans tous les cas. Lorsque l'explorateur ne permet pas de cookie de session, PHP ajoute automatiquement le paramètre PHPSESSID à l' URL.
De plus,
"INTERDIRE LE PASSAGE DE FONCTION DANS UNE URL " ce titre n'a aucun rapport avec le contenu du script: Sait tu au moins ce qu'est une fonction ?
10 mai 2013 à 16:01
10 mai 2013 à 15:05
Par contre je dis que entre tes lignes "magiques" et la redirection il se passe tout un tas de truc... et ça ce n'est pas ce qu'on peut appeler une sécurisation.
Les lignes que je t'avais proposé proposées permettent de mettre en évidence ce problème et montre l'absence de sécurisation de la solution que tu proposes.
Si les utilisateurs de PHPCS que ce n'est pas grave de laisser des failles de sécurité et que ton code va les protéger... ils vont au devant des problèmes.
10 mai 2013 à 14:37
10 mai 2013 à 14:29
rajoute un ? un . un chiffre une lettre et sa plante
------------------------------
ha ha ha, c'est nouveau comme comportement... je croyais que ça faisait une redirection... tu commences à t'embrouiller on dirait ;)
------------------------------
rajouter echo script ces évident que cela va généré une boite d'alert donc sa n'a aucune utilité
------------------------------
En tout cas, c'est cool, c'est exactement ce que je voulais que tu admettes...
Ca ne bloque rien, donc ça ne sécurise pas. Fin de la discussion.. (ou comme tu dis: que cela te plaise ou non).
10 mai 2013 à 13:04
Emilia, pourquoi voudrais tu que je remplace mes lignes de codes par les tiennent puisque moi sa fonctionne, rajouter echo script ces évident que cela va généré une boite d'alert donc sa n'a aucune utilité, en laissant mon code tu ne sais rien faire dans la barre d'adresse, rajoute un ? un . un chiffre une lettre et sa plante, fin de la discussion que cela te plaise ou non
10 mai 2013 à 12:03
Sinon on peux aussi créer des sous-domaines CNAME (ex: fr.monsite.tld) et s'en servir (car la récupération du langage par l'en-tête n'est pas forcement une bonne idée).
Comme ça, la solution est radicale est simple: plus de problèmes ^^.
Cordialement.
10 mai 2013 à 11:22
mais comme tu l'Einstein du php forcément tout le monde a tort sauf toi
---------------------
contrairement à toi, je teste tout ce que je propose et surtout je teste aussi l'intégralité des remarques qui me sont faites.
C'est comme cela qu'on peut progresser.
Donc pour tester, je te propose de remplacer les 3 dernières lignes de ton code par les lignes ci dessous.
-------------
if($extension)
{
echo '<meta http-equiv="refresh" content="0;URL=.......">';
echo "<script>alert('Voici les parametres supplémentaires traités avant redirection : '+window.location.search);</script>";
exit();
}
--------------
Et d'appeler ta page avec des paramètres supplémentaires.
D’après ce que tu dis, il ne devrait y avoir que la redirection (et aucune alerte javascript), et donc le code serait sécurisé.
Moi je te dis, après l'avoir testé, que l'alerte javascript est bien affichée avant la redirection. Elle présente les paramètres supplémentaires qui sont envoyés à la page (et donc au serveur).
Donc si à la place d'une alerte javascript, il y avait eu une portion de code avec une faille de sécurité, il pourrait y avoir des problèmes.
J'invite d'ailleurs les autres utilisateurs à tester et à se faire leur propre idée avant d'utiliser ces lignes sur leur propre site.
10 mai 2013 à 09:23
10 mai 2013 à 09:05
Le but de ces 2 lignes c'est de te montrer que tu te trompes en pensant que ton script permet de SECURISER une page.
En effet, au niveau du serveur le code :
--------------------------
echo '<meta http-equiv="refresh" content="0;URL=l'adresse de votre choix">';
--------------------------
a autant d'effet que
--------------------------
echo 'bonjour';
--------------------------
Tu n'arrives pas à le comprendre, mais pourtant l'intégralité du code qui se trouve après cet "echo" est traité..... donc il n'y a aucune sécurité dans ton système.
Tant que tu penseras et que tu annonceras que ton script sécurise quelque chose, tu seras dans l'erreur.
Après, je ne peux pas te forcer à te remettre en question, mais au moins espérer que les autres utilisateurs de ce site n'utilisent ta source en pensant sécuriser leur page web.
9 mai 2013 à 13:02
9 mai 2013 à 11:04
à la suite de tes "soit disant" lignes magiques, je te propose de mettre le code suivant :
--------------------
echo "oups, ca ne marche pas en fait";
echo "<script>alert('heuu non ca ne marche pas');</script>
exit();
--------------------
En théorie, si ton code est si magique, il ne devrait pas y avoir de message si l'alerte javascript ;)
Pour info, j'ai testé donc je connais la réponse évidemment.
Alors ton code il est magique ou pas?
8 mai 2013 à 17:12
8 mai 2013 à 07:31
---------------------------------------------------
je n'aie pas de ? dans l'url ni aucun autre paramètre
---------------------------------------------------
Si c'est cela et que tout est parfait, à quoi sert ton code (et pas ta fonction car il n'y a pas de fonction dans ton code)?
bon là j'avoue... tu es venu à bout de ma patience.
Je te laisse continuer dans ton état d'esprit fermé à toutes remarques...
Je maintiens que ton code ne sécurise rien contrairement à ce que tu dis et qu'il ne faut surtout pas l'utiliser dans ce but.
7 mai 2013 à 23:08
7 mai 2013 à 22:56
Il peut y avoir quelques petites coquilles j'ai fais ca à la main.
-----------------------
<?php
//fonction a appeler pour surveiller l'url
function securisationURL(){
//url a utiliser en cas de probleme (pour pourrait recuperer l'url sans la querystring)
$urlErreur= 'htpp://www.google.fr';
//on verifie les parametres de l'url
//la variable QUERY_STRING contient l'ensemble des donnees
// apres le ? dans l'url
if (
(is_array($_SERVER))&&
(isset($_SERVER['QUERY_STRING']))&&
(trim($_SERVER['QUERY_STRING'])!=='')
) {
//on verifie si les entetes ne sont pas deja envoyees
if (headers_sent()===FALSE){
//on redirige l'internaute
header('Location: '.$urlErreur);
//on termine definitivement le traitement de la page
exit;
}else{
//on affiche un message de compatibilite
echo '<meta http-equiv="refresh" content="0;URL='.$urlErreur.'">';
echo '["'.$urlErreur.' Cliquez ici]';
//on termine definitivement le traitement de la page
exit;
}
}
}
//on appelle la fonction de securisation a appeler LE PLUS TOT possible
securisationURL();
?>
-----------------------
avec :
- des commentaires
- une vraie déclaration de fonction
- pas d'utilisation de variable quand ce n'est pas nécessaire
- pas d'utilisation de fonction, de concaténation ou d'explode quand ce n'est pas nécessaire
- des conditions propres
- l'emploi de fonction appropriée selon le cas de figure (header location si les entêtes ne sont pas déjà envoyées, sinon la balise meta + un lien)
- l'ajout un exit(); pour forcer l’arrêt du traitement (et éviter de poursuivre dans le code qui est après.
7 mai 2013 à 22:47
Si il n'y a pas de déclaration de fonction, il ne faut pas parler de fonction... sinon cela embrouille le lecteur.
Pour ce qui est de la sécurisation c'est bien ce que je dis... ce script ne fait pas ce que tu attends qu'il fasse... il ne sécurise rien du tout.
Quand le navigateur demande une page avec ?variable=code_diabolique il se passe les étapes suivantes :
---------------------
1) Appel du serveur pour demander la page avec "?variable=code_diabolique"
2) Début du traitement de la page avec "?variable=code_diabolique"
3) Exécution de TOUT le code situé avant tes lignes de code avec "?variable=code_diabolique"
4) Exécution de tes lignes de code, le résultat est simplement du code HTML éventuellement envoyé à l'internaute... rien ne force le serveur à s’arrêter à ce moment là... pour le serveur c'est un simple "echo" rien de plus.
5) Poursuite du traitement de la page avec "?variable=code_diabolique"
6) Exécution de TOUT le code situé après tes lignes de code avec "?variable=code_diabolique"
7) Fin du traitement de la page avec "?variable=code_diabolique"
---
8) Le navigateur de l'internaute prend (éventuellement) en compte la balise meta que tu as envoyé en 4)
9) le navigateur demande alors la page sans ?..... => retour en 1) mais sans "?variable=code_diabolique"
---------------------
Les lignes 3 et 6 sont exécutées au moins 1 fois intégralement.
Il y a bien une redirection, mais celle ci n'est effective qu'après le traitement intégral de tout le code de ton fichier PHP.
Si il y a eu une faille de sécurité dans le code qui précède ou qui suit tes quelques lignes, alors ton site est foutu...
Je le répète ton script ne protège absolument rien et ne doit pas être utilisé dans ce but.
7 mai 2013 à 19:45
7 mai 2013 à 18:40
-----------------------------
petite fonction toute simple qui permet d'interdire le passage de paramètre supplémentaire dans une url, cela a pour avantage de contribuer à sécurisé un site
-----------------------------
Je remarque juste que :
- tu parles de "fonction" alors qu'il n'y a pas de fonction dans ton code
- tu parles de "interdire le passage de paramètres supplémentaires dans l'url" donc un débutant pourrait penser que cela sécurise contre tous les types de paramètres.
- tu parles de "sécuriser un site" alors qu'il n'y a aucune sécurité (ton code n’arrête pas le traitement normal d'une page)
Pourquoi ne pas vouloir prendre en compte la moindre remarque effectuée ici?
7 mai 2013 à 18:20
7 mai 2013 à 17:24
Juste pour préciser une dernière fois... ton script (dans l'état) ne sécurise rien.
Il ne bloque pas l’exécution de la page avec les paramètres dans l'url.
Si quelqu'un pense se protéger, par exemple d'une injection SQL ou de choses comme ça, il se trompe.
7 mai 2013 à 16:50
7 mai 2013 à 11:08
Un peu embêtant quand on as un gros site...
Perso, je préfére ce petit bout de htaccess:
RewriteCond %{QUERY_STRING} ^(.*)base64_encode(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)GLOBALS(=|[|%[0-9A-Z]{0,2})(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)_REQUEST(=|[|%[0-9A-Z]{0,2})(.*)$ [OR]
RewriteCond %{QUERY_STRING} ^(.*)(SELECT|INSERT|DELETE|CHAR\(|UPDATE|REPLACE|LIMIT)(.*)$
RewriteRule (.*) – [F]
Cordialement
7 mai 2013 à 08:31
Si tu ne prends pas en compte les commentaires (enfin si tu les rejettes tous) ce n'est pas la peine qu'on perdre du temps à t'en faire.
Donc je dirais même, pourquoi nous montrer ton "code" ?
--------------------------
le fait d'utiliser les guillemets et apostrophes évite d'utiliser les antislash
--------------------------
rien à voir avec les antislashs....
les guillemets demandent PHP de rechercher des variables dans le texte ($...) et à faire les remplacements qui s'imposent.
Avec les simples quottes, PHP ne fait aucun traitement.
Cela ne doit pas être une question de "confort".
De plus il y a une perte de performances lorsque des variables sont incluses dans les guillemets en comparaison d'une concaténation simple.
--------------------------
pourquoi toujours cherché à faire des codes hyper compliqués
--------------------------
C'est justement parce que ton code est trop compliqué (par rapport à ce qu'il fait) qu'on te fait des remarques.
Après si tu penses que c'est inutile de :
- faire des vérifications propres,
- vérifier l'existence des variables,
- être constant dans l'écriture du code PHP,
- utiliser le moins possible de valeur en dur,
- ou être pointilleux dans les noms utilisés
... alors tu vas au devant de gros problèmes avec tes développements avec :
- des failles de sécurité
- des problème de fonctionnement,
- des problème de relecture de ton code après 1 mois sans y avoir touché, etc...
Exemple de test "simple" et de faille de sécurité :
Par exemple oui, pour PHP 0=='mot de passe super sécurisé'
C'est une faille de sécurité très basique et très facile à exploiter.
Tu peux tester ici :
http://sandbox.onlinephpfunctions.com/code/26b0f9aaa9ecea8304dcd34dc27166448fc97fec
--------------------------
url est présent car il est utiliser ailleurs pour d'autre nécessité
--------------------------
Et alors?
Si tu utilises une même donnée à 20 endroits, tu utiliserais donc 20 variables?
Tu nous montres un code que tu considères en "initié", il doit donc être propre.
EM.
6 mai 2013 à 16:35
6 mai 2013 à 11:45
Il y a un problème à pratiquement chaque ligne :( ca ne PEUT PAS être un code initié.
1) aucune classe ni fonction PHP => c'est à banir d'un développement "initié"
2) il n'y a aucun commentaire dans le code => c'est obligatoire dans un développement "initié"
3) parfois il y a utilisation des "..." et parfois des '...' Pour une simplification de la lecteur, il faudrait essayer d'utiliser tout le temps le même (et de préférence les simples quotes)
4) dans le code :
----------------------------
$url = "http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
$chaine = $url;
----------------------------
à quoi sert la variable "$url" ?
A rien, elle est simplement recopiée dans $chaine puis n'est plus utilisée...on peut donc mettre $chaine sur la 1ere ligne, cela évitera d'utiliser de la mémoire pour rien.
5) dans le code :
----------------------------
$extension = $tab[count($tab)-1];
----------------------------
Il n'y a aucune vérification sur l’existence de la case du tableau... même si cela ne semble pas pouvoir se produire il faut prendre l'habitude d'effectuer des vérifications.
6) ce type de condition
----------------------------
if($extension)
----------------------------
est vraiment à bannir...
Exemple : si je passe http://www.monsite.be/0 (c'est un zero à la fin) alors il la vérification échoue, alors que pourtant il y a bien du code apres le délimiteur.
dans les conditions il faut TOUJOURS être strict c'est à dire :
- TOUJOURS comparer 2 éléments entre eux
- TOUJOURS comparer le type de ces 2 éléments (test strict)
donc la cela pourrait être :
----------------------------
if (trim($extension)!=='')
----------------------------
on compare $extension à la chaine de texte ''et surtout le fait d'utiliser !(ou) force aussi PHP à comparer le type des 2 éléments.
7) il faut utiliser des noms de variables qui sont compréhensible
par exemple :
- avec "$extension" on pourrait penser à l'extension du nom de domaine, mais ca n'est pas le cas (quel est le rapport entre une extension et le texte à la fin d'une URL ?)
- avec "$chaine" qui est générique et qui ne dit pas ce qu'il y a dans la variable
8) dans le code
--------------------------
echo '<meta http-equiv="refresh" content="0;URL=l'adresse de votre choix">';
--------------------------
pourquoi ne pas utiliser une variable à la place de "l'adresse de votre choix".. c'est vraiment pas top d'avoir à rechercher dans le code HTML une variable à adapter.
Il y a des variables déclarées mais qui ne servent pas, là c'est le contraire, cela pourrait servir mais il n'y a rien.
9) enfin le meta :
--------------------------
echo '<meta http-equiv="refresh" content="0;URL=l'adresse de votre choix">';
--------------------------
Si ce "code" est utilisé n'importe où dans la page, au mieux il sera juste inefficace...
Pourquoi ne pas utiliser "header(...)" en vérifiant que les entêtes n'ont pas déjà été envoyées ?
Le fait d'utiliser un simple "meta" fait que l'intégralité du code PHP est exécuté même si l'url est censée être "protégée".
10) enfin et pour finir... le principe de fonctionnement du code PHP
Au lieu de faire des explodes et des tests bizarres sur des variables écrites en dur dans le code... il faudrait partir des variables "server" que proposer PHP à savoir :
$_SERVER['REQUEST_URI'] => url apres le nom de domaine
ou
$_SERVER['QUERY_STRING'] => url après le ? (si il y en a un)
du coup un simple "trim(...)" sur l'une des 2 variables au dessus donne un résultat beaucoup plus précis et ne nécessite aucune adaptation du délimiteur ni aucun découpage de chaine.
Désolés d'être brutale comme cela, mais parler de sécurité, indiquer un niveau "initié" mais avec un "code" comme celui présenté, ce n'est pas bon.
Un utilisateur débutant pourrait penser que c'est un exemple à suivre alors que non.
conseils :
1) créer une classe et des fonctions pour regrouper tout ton code
2) vérifier quelque chose de précis (utiliser des tests stricts )
3) être un peu plus pointilleux (simple quote, nom des variables, utilisation des variable, etc)
4) revoir un peu la logique de fonctionnement (quelle variable tester, et comment effectuer la redirection)
bonne continuation
EM.
4 mai 2013 à 02:11
de 2 : le délimiteur étant dans l'exemple .be, si l'url est http://www.monsite.be, le simple fait de mettre un ? dans l'url et ou tout autre signe ou commande fait automatiquement rediriger
de 3 : j'aie préciser que cela s'utilise sur des url propre qui rewriter donc sans paramètre au départ d'où l'intérêt de la fonction
3 mai 2013 à 23:25
Et enfin, en quoi il est obligatoire d'utiliser une meta refresh? header() est parfaitement utilisable dans le cas présent.