1. Accueil
  2. Tous les snippets
  3. Snippets PHP
  4. Interdire le passage de fonction dans une url

Interdire le passage de fonction dans une url

Soyez le premier à donner votre avis sur cette source.

Snippet vu 5 186 fois - Téléchargée 14 fois

Commenter

Contenu du snippet

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 en plus des autres mesures, cette fonction est surtout interressante si vos url sont propres c'est à dire rewriting, l'utilisation de la fonction meta refresh est dans ce qu'à si obligatoire car d'autre fonction php étant utiliser avant ce script, header location ne peu fonctionner

Source / Exemple : 


$url = "http://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
$chaine = $url; 
$delimiteur = ".be/"; 
$tab = explode($delimiteur, $chaine); 
$extension = $tab[count($tab)-1];
if($extension)
{
echo '<meta http-equiv="refresh" content="0;URL=l'adresse de votre choix">';
}

Conclusion :


le délimiteur de l'url ces .be, libre à vous d'utiliser l'extension désiré

A voir également

Ajouter un commentaire

Commentaires

Signaler
kankrelune
Messages postés
1293
Date d'inscription
mardi 9 novembre 2004
Statut
Membre
Dernière intervention
21 mai 2015
Autant faire un htaccess...

@ tchaOo°
Signaler
cs_christophedlr
Messages postés
256
Date d'inscription
samedi 3 janvier 2004
Statut
Membre
Dernière intervention
30 mai 2016
 4 > kankrelune
Messages postés
1293
Date d'inscription
mardi 9 novembre 2004
Statut
Membre
Dernière intervention
21 mai 2015
Surtout qu'il parle de l'URL Rewriting, donc son code n'a aucun intérêt.

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.
Signaler
janhsh
Messages postés
6
Date d'inscription
samedi 10 octobre 2009
Statut
Membre
Dernière intervention
21 février 2019
Nombreuses erreurs de sémantiques

1:
Pourquoi en ligne 2 
$chaine = $url;
?
Cette opération ne sert à rien, ,
Il suffit d'écrire en ligne 4 
$tab = explode($delimiteur, $url);
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 ?
Signaler

inutile de perdre notre temps car on ne tombera pas d'accord, si tu va sur mon site et que tu rajoute n'importe quoi dans l'url tes redirigés et comme je l'aie dit ça vient en complément des autres mesures habituel. ça nécessite aussi des url propre rewrité avec le htaccess pour que aucun paramètre n'apparaissent dans l'url, pour le reste pense en ce que tu veux
Signaler
cs_emilia123
Messages postés
122
Date d'inscription
mercredi 19 décembre 2001
Statut
Membre
Dernière intervention
5 janvier 2009
Il faut relire toute la conversation... je n'ai JAMAIS dit que cela ne provoquait pas la redirection :)

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.
Afficher les 31 commentaires
S'inscrire maintenant

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.

Du même auteur (michael33512)