Url rewriting et failles de sécurité PHP

[NetCodeur]

Bonjour.

J'aimerai savoir si l'URL REWRITING réduisait les failles de sécurité pour un site codé en PHP.

Est-ce que les variables GET et POST ne seront plus visibles : au lieu d'avoir une URL du type :

Code: Tout sélectionner

index.php?page=1&active=1

j'aurai celle-ci rewritée ainsi :

Code: Tout sélectionner

activer.php

En gros ma question est donc : est-ce qu'une personne malveillante pourrait identifier mes variables bien que j'ai pris l'attention de rewriter mes URL ?

Merci à tous.[/code]

[ruben07]

Rewriter ne sécurisera pas plus ton site. Si tu estimes que ton script est vulnérable et que tu pourrais te faire "attaquer", corrige le c'est ce que tu as de mieux à faire.
Je vois pas ce que tu veux dire pour les variables get et post ??

[fabdecoupe]

pour sécuriser ton site par rapport à tes variables Get ou Post, tu peux traiter celle-ci à l'arrivée et vérifier le protocile utilisé pour savoir comment elles sont arrivée

pour le rewritting d'url, en asp on arrive à ceci

page.asp?id=27&param=23

en

page_27_23.html

bien sur cela dépend du soft de rewriting que tu vas utliser et comment tu vas paramétrer celui-ci

[e-kiwi]

>> J'aimerai savoir si l'URL REWRITING réduisait les failles de sécurité

non, pas réellement. c'est à toi de coder proprement

[rafgug]

Salut!
Le seul avantage que je vois c'est le typage des variables: bon nombre de programmeurs oublient de vérifier si la varible qu'ils utilisent (récupérée par GET) est bien un entier -par exemple-. Ben là, si tu défini correctement ta règle, tout ce qui n'est pas entier ne passera pas!

@++

R@f

[phpmikedu83]

Salut!
Le seul avantage que je vois c'est le typage des variables: bon nombre de programmeurs oublient de vérifier si la varible qu'ils utilisent (récupérée par GET) est bien un entier -par exemple-. Ben là, si tu défini correctement ta règle, tout ce qui n'est pas entier ne passera pas!

@++

R@f

On en revient au même, si t'es une truffe en codage PHP, alors pourquoi tu ne le serais pas en définission des règles de rewritting? lol

[rafgug]

On en revient au même, si t'es une truffe en codage PHP, alors pourquoi tu ne le serais pas en définission des règles de rewritting? lol

Bah, être un boolay, c'est tout un art, on peut pas l'être partout...
Plus sérieusement, quand tu défini une règle, tu penses à son type, tandis qu'oublier un controle de donnée, est plus facile, enfin c'est ce que je pense!

@++

R@f

[fabdecoupe]

normalement on fait du re-writing pour le référencement, donc pour le frontOffice,

on référence un site pour attirer des Internautes, afin que ceux-ci puissent venir surfer sur celui-ci,

alors pourquoi parler sécurité à se niveau ?

j'ai déjà travaillé sur des sites en re-writing avec partie protégée,

les pages se trouvant après l'accès privé, ne passe pas à la moulinette du re-writing

ne pas oublier que le re-writing d'url se fait sur le nom des pages, donc on peut utiliser une règle qui travaille comme ceci

pageok.asp?id=2
devient = pageok_2.html

et
pageko.asp?id=2
reste = pageko.asp?id=2

il n'y a pas de faille de sécurité ici, puisque l'on affiche du contenu visible pour l'Internaute

[phpmikedu83]

On en revient au même, si t'es une truffe en codage PHP, alors pourquoi tu ne le serais pas en définission des règles de rewritting? lol

Bah, être un boolay, c'est tout un art, on peut pas l'être partout...
Plus sérieusement, quand tu défini une règle, tu penses à son type, tandis qu'oublier un controle de donnée, est plus facile, enfin c'est ce que je pense!

@++

R@f

Je pensais pas aux bons à rien, mais aux mauvais en tout, je dois l'avouer

@+

[rog]

lol
@fabdecoupe

la je ne suis pas daccord

si

pageok.asp?id=2
devient = pageok_2.html

et si id est vulnerable

pageok_www.monsite.com/mabackdoor.gif.html

risque d'injecter le script contenu dans mabackdoor.gif

de fait le rewriting ne securise pas une faille php/asp injection mais difficulte la recherche

style une recherche google inurl:page=
ne rapportera pas ton site

rog

[dadovb]

ce sont deux choses différentes, l'un n'influe pas sur l'autre ( ou alors légèrement, puisque le nom des variables utilisées peut-etre caché) :

index-125-4-7.html

est moins lisible que :

index.php?article=125&categ=4&unite=7

[fabdecoupe]

lol
@fabdecoupe

la je ne suis pas daccord

si

pageok.asp?id=2
devient = pageok_2.html

et si id est vulnerable

pageok_www.monsite.com/mabackdoor.gif.html

risque d'injecter le script contenu dans mabackdoor.gif

de fait le rewriting ne securise pas une faille php/asp injection mais difficulte la recherche

style une recherche google inurl:page=
ne rapportera pas ton site

rog

comme je l'ai expliqué plus haut, ce qui est vulnérable peux rester tel quelle, (ne pas le passer à la moulinette re-writing)

si le contenu peux-être accessible par tous, je ne vois pas ce qui peux provoquer le problème que mr X écrive ceci page_21.html en lieu et place de page_2.html, si cette page n'existe pas, il aura comme retour un message d'erreur, et si cellec-i existe bien il aurat le résultat afficher sur son écran

[NetCodeur]

ce sont deux choses différentes, l'un n'influe pas sur l'autre ( ou alors légèrement, puisque le nom des variables utilisées peut-etre caché) :

index-125-4-7.html

est moins lisible que :

index.php?article=125&categ=4&unite=7

Voila ce que je voulais dire : ici les variables peuvent même être cachées :

Code: Tout sélectionner

index.php?page=1

peut devenir :

Code: Tout sélectionner

accueil.html

Résultat : l'url rewritée ne montre pas de variable ni de paramètre mais est-ce pour autant que le code sera sécurisée ?

[rog]

lol

bah oui elles seront executées

c'est justement le but de la manoeuvre

rog

[NetCodeur]

lol

bah oui elles seront executées

c'est justement le but de la manoeuvre

rog

???? Qu'est-ce qui sera executé ????