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é
@ tchaOo°
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.
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 ?
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.
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.