j'ai une fonction PHP (comprendre par fonction le terme en langage français et non en langage PHP, non pas "function" mais une partie d'application) dans un répertoire A. j'ai la même fonction mais allégée de certaines dispositions dans un répertoire B.
 
Selon qu'on est affecté à la fonction pleine (A) ou à la fonction allégée (B) on est redirigé vers le dossier A ou B.
 
Les fichiers ne sont pas identiques (même par leur nom) mais relativement proches.
 
Un petit malin affecté à l'allégée qui s'amuse à éditer ses url peut avoir accès à des dispositions auxquelles il n'a pas droit.
 
Etant donné que ce sont des dossiers distincts, dans le dossier A j'ai mi un fichier .htaccess très très très simple:  "deny from all". Basta.
 
Ca change rien du tout oui, on peut éditer tout ce qu'on veut et se servir aux fraiS de la princesse!!!
Par contre quelqu'un d'autorisé pour la fonction pleine ne peut plus se connecter.
 
Comprend pas.

ok je comprend en partie ton probleme mais ça manque d'information. Tu as des parametres et celon les parametres il peut acceder à un endroit à laquelle il n'a pas le droit.
 
Quel sont les parametres?

Selon le type d'identifiant il accède à la fonction totale (A, hébergée dans le dossier A), ou à la fonction allégée (B, hébergée dans le dossier B).
Mais si un utilisateur B édite l'url une fois connecté il peut (à condition de connaître les chemins adéquats certes) accéder à des fonctions interdites pour lui (donc en gros il bascule sur le dossier A).
 
je voudrais rendre totalement hermétique le basculement de B vers A, même avec du trafficotage d'url.

Je comprend un peut mieux. B n'a pas le droit d'aller sur A ?
Essais de passer par le cookie + session. S'il est connecté en tant que B il se fait jeter par un fichier present dans tous t'es fichier present dans le repertoire A en faisant un include.

c'est à dire que pour PHP le connecté est le même dans les 2 cas, (et il faut que ça soit ainsi pour que la fonction soit opérationnelle). Le cookie ne marche donc pas. les identifiants ne sont pas les mêmes mais au final ils ont le même cookie de connection. B est A, en version bridée.
 
C'est pour ça que j'avais pensé au htaccess

PS. Quel est le terme "officiel" pour cette pratique qui consiste à éditer l'url pour exploiter des failles?  Ca m'aiderait peut être pour Google.

ok mais y'a bien un moment  (identifications ?) où tu fais la différence entre ceux qui vont sur A et ceux sur B
 
à ce moment là faudrait propager une variable (à la rigueur dans le cookie, ou sinon une session) qui autorise B
 
sinon tu peux aussi faire une vérif sur B, mais faudrait nous en dire plus sur comment fonctionne ton truc

 
 
exploiter une faille grande ouverte malheureusement
 
si c'est controlé uniquement par l'url, c'est à la vue de n'importe qui et modifiable à loisir

oui je suis daccord parce que là ça nous étonnes que via l'url ont puisse passer une porte sans probleme. Cela voudrait que personne est clairement unique derriere A ou B.

A: fonction totale
B: fonction bridée  
 
UserB est associé à UserA, et ce détail est important. UserB est une partie de UserA
 
A l'identification il y a un détail (que je ne révèle pas trop, mais faite moi confiance) qui dit que UserB est bridé il n'y a aucun doute là dessus. Il est redirigé vers la fonction B donc. Mais dans le process PHP son login est changé en UserB (mais ça ne se voit pas). car UserB est une partie de UserA ! Voilà pourquoi il peut éditer l'url.
cela dit certains détails du login de UserB ne trompent pas. Effectivement on pourrait propager une variable par ce biais, et mettre une sorte de "douane" dans la fonction A qui empêche son utilisation.
 
cela dit cett efonction A est une focntion de production assez sensible et ça m'ennuie un peu de la toucher en profondeur. je préfèrerais infiniment jouer sur htaccess. Si possible.

que A soit une partie de B ou pas change rien au problème
 
t'as une variable ou un chemin qui n'est pas vérifié ou alors pas suffisamment, le problème est là, pas ailleur
 
un htaccess va rien résoudre à la faille qui vient plus du code du script

>Mais dans le process PHP son login est changé en UserB (mais ça ne se voit pas). car UserB est une partie de UserA !
Que UserB soit une partie de UserA ne change rien au fond du problème : il te faut absolument pouvoir faire la différence entre UserA et UserB, autrement que par l'url. Tant que rien ne te permettra de faire cette différence, tu seras bloqué

J'ai utilisé une astuce.
 
UserB est toujours UserA mais
 
l'appellation de la variable dans PHP a été changée de quelques caractères dans la fonction allégée B  (Valid_user a été changé en Valid_utildeB par exemple)
 
résultat des courses:  
 
Quand on fait le malin en traffiquant les url on accède effectivement à la peinture, au graphisme de la fonction A, mais le contenu est vide (ce qui est sensible donc), désespérément vide.
 
Estèce que ça vous parait acceptable d'un point de vue de sécurité?

comment veux-tu qu'on te dise si c'est bien, si ça tombe y'a des trous dans tous les sens et un mec un peu malin pourrait tout péter
 
t'as filé aucune info, aucun code ni url, donc forcément c'est à toi de voir

dans un cas (la page appelée):
 

dans l'autre

 
Bien entendu à l'identification dans un cas ça produit 'Valid_user', dans l'autre ça produit 'Vlid_utildeB' .
 
Les premiers caractères des logins fonction A et B ne sont pas les mêmes c'est là dessus que se fait la distinction. La redirection vers l'une ou l'autre des fonction est incontournable, je ne me fais pas trop d esouci là dessus.. ce qui est plus sensible est le basculement de l'une vers l'autre.

et ça serait pas plus simple de faire une vraie variable de session $_SESSION['DroitAcces'] avec dedans A ou B ?
 
et dans ton B si la variable est pas là tu fais un return false sur la première ligne et basta
 
EDIT : ça tourne en prod ce genre de truc

de toute façon moi je capte rien à cette histoire.
- je capte pas ce qu'est une "fonction" en terme français, pas "function". Si c'est bien ce que je pense, ça s'appelle des scripts
- je capte pas pourquoi tu pourrais pas faire la différence entre userA et userB. Tu dis que tu as un protocole d'identification. Bah par exemple si c'est un userA tu rajoutes une variable de session qui le dis, et dans tes scripts "Fonction A" tu interdis l'accès aux utilisateurs qui ne possèdent pas cette variable de session.
- je capte pas comment renommer une fonction pourrait être une mesure de sécurité.
- je capte pas pourquoi ça serait pas un problème classique d'authentification avec des niveaux de permission. Si permissionUser > niveauA, autoriser Fonction A. Donc je capte pas ces magouilles d'url, et de fonction pas function.
 
'fin bref, je capte rien à ta problématique, j'ai bien l'impression que tu te prends la tête pour rien, et vu que tu expliques quasi rien ...

 
En prod quand on a une fonction qui marche on évite de la toucher sans remuer 7 fois sa langue dans sa bouche. le processus que j'ai trouvé estpeut être exotique mais il a le mérite de tourner sans toucher à la fonction A.

je m'étonne pas que tu touche pas à un code en prod, je m'étonne qu'on puisse mettre en prod ce genre de code
 
et puis quand y'a une faille, prod ou pas faut corriger
 
et c'est pas exotique, c'est surtout étrange, si y'avais déjà une variable de session, le problème devait venir d'ailleurs, l'url modifie pas la session (en principe..)

ouais enfin juste rajouter un return false en début de fonction, en fonction d'une variable de session, je vois pas trop comment ça pourrait avoir des conséquences graves.