URL identiques sur chaque page ? [Résolu]

JmL40 · 19/02/2008, 17h12

Bonjour,

Ayant développer une application web en PHP/MySQL, je souhaite la sécuriser au maximum.

J'ai déjà résolu un premier niveau de sécurité qui a mon sens reste basique, à savoir l'accès direct à une page par saisie de l'url (ex : www.monsite.fr/page1.html). Dans mon cas, si l'utilisateur n'est pas "logué" et enregistré, celui-ci est automatiquement redirigé vers la page d'authentification.

Bref, ce premier niveau de sécurité fonctionne parfaitement. Vous allez donc me dire mais pourquoi vouloir plus ?. D'une part pour apprendre, mais aussi pour avoir une application 100% fiable et sécurisée.

So ? what's my probleme

!

En d'autres termes, je souhaiterai que l'utilisateur qui consulte les différentes pages de l'application ne voit qu'un seul et unique URL par exemple, www.monsite.fr.
www.monsite.fr serai visible tout au long de la consultation.

J'ai donc fait des recherches sur le principe, les méthodes, j'ai consulté ce topic en premier :

http://web.developpez.com/tutoriel/apache/urlrewriting/

J'ai réussi à mettre en oeuvre la première méthode, et échoué sur les suivantes. Cependant, tout cela ne correspond pas à mes attentes ...
Je demande donc votre aide !

Merci à tous

_Mac_ · 19/02/2008, 17h54

Hello,

Il y a 2 méthodes seulement pour toujours voir uniquement "http://www.tonsite.com/" dans la barre d'adresse :

Utiliser des frames. C'est de très loin la méthode la plus simple
Faire toute la navigation de ton site en POST : quand tu cliques sur un lien, en fait tu actives un JavaScript qui va poster un formulaire sur /index.php qui va renvoyer la page demander. C'est super lourd.

3 remarques à ce propos :

Quelque soit la solution (surtout la 2ème quand même), l'indexation de ton site ne va pas être terrible
Tes pages seront peu ou pas "bookmarkables"
Limiter l'affichage de l'adresse n'a rien à voir avec la sécurité de ton site

JmL40 · 20/02/2008, 08h34

Bonjour,

Tes remarques ont bien été prise en compte, tout cela reste sommaire dans ce cas la.

Doit-je donc m'en tenir à mon premier niveau de sécurité ou vous me conseillez une autre solution toujours au niveau de la sécurité?

A vrai dire, je veux sécuriser un maximum mon application, que puis-je employer comme méthode encore ?

Merci pour ton explication !

Cordialement

_Mac_ · 20/02/2008, 10h55

Sécuriser, c'est un bien grand mot : il veut dire quoi pour toi, exactement ? Sécuriser, c'est par exemple vérifier que son serveur ne présente pas de faille connue. Ca, c'est surtout si tu héberges toi-même ton site ou si tu es sur un serveur dédié, car si tu es hébergé mutualisé, c'est l'hébergeur qui est responsable de cette partie. Y a des outils genre Nessus pour faire un audit.

Sécuriser, ça veut dire aussi s'assurer que son site (partie HTML/PHP, etc.) ne présente pas de défaut. Là, c'est beaucoup plus difficile à voir car c'est pas en cachant les URL ou en mettant une protection par login/mot de passe qu'on peut s'en prémunir

La cible, c'est tous les scripts PHP de ton site, en particulier :

les scripts d'upload : vérifier qu'on ne peut pas uploader un fichier contenant du code PHP par exemple et l'appeler ensuite.
envoi de mail : vérifier qu'on ne peut pas forger un en-tête SMTP.
Base de données : vérifier que son code n'est pas sensible à l'injection SQL.
URL : ne pas y faire figurer les infos sensibles genre mots de passe, nom de script, etc. bref, tout ce qui pourrait tenter qq'1 de bricoler les URL.

Y en a des tonnes d'autres, et là, à ma connaissance, y a pas d'outils automatiser pour vérifier tout ça

Faut chercher sur le Web s'il y a des tutos ou des exemples de hack pour vérifier que ton site n'y est pas soumis.

N.B. : je disais que masquer l'URL n'est pas une solution car il suffit de faire un clic droit + propriétés pour voir la vraie URL de la page. Dans tous les cas, si qq'1 veut attaquer ton site, il saura très bien forger les URL qui l'intéressent.

JmL40 · 20/02/2008, 12h17

Merci pour tes explications claires.

En fait, je pense oublier cette méthode car comme tu le dis "tout est possible" !

En somme je vais donc établir une liste de points a vérifier sur l'ensemble de mon application, noms des variables, fichiers uploads, formulaires et autres.

Cette vérification me permettra de réduire au maximum les risques ...

Pour finir, et pour répondre à ta question, la sécurite pour moi dans cette application se résume à cette idée :

> Gérer & eviter les éventuelles erreurs provoquées par les utilisateurs (en spécifiant une page par url par exemple) par différentes actions, sachant que ces utilisateurs sont novices.

(Précisons que l'application est en intranet)

Voila merci pour tout ! Cordialement

ps: Je test actuellement Nessus ...

_Mac_ · 20/02/2008, 13h32

Si c'est en intranet, y a moins de risques de piratage (enfin, on peut espérer).

Y a surtout 2 choses à voir pour ton cas :

s'assurer que les formulaires vérifient bien ce qu'on envoie (point que j'ai oublié de mentionner). Par exemple, tu as un champ qui attend un entier. Faire une vérif en JavaScript, c'est bien, mais il faut aussi que le serveur fasse la vérification. Idem pour les zones de texte qui servent ensuite à un affichage : au moment de l'affichage, il faut bien penser à encoder en HTML la chaîne à afficher, ce afin d'éviter que les éventuelles balises <script> ou autre ne soient interprétées par le navigateur à l'affichage.
Les URL : éviter comme je disais de mettre des trucs trop sensibles dans les URL comme des noms (de personne), des identifiants trop évidents (par exemple, numéro d'employé) ou des noms de fichiers. Le coup du numéro d'employé, tout dépend de ce pour quoi tu l'utilises mais pas exemple, si ton appli est un truc qui permet à tous les individus de la boîte de modifier leurs coordonnées personnelles, et si la page qui affiche le formulaire s'appuie uniquement sur le numéro d'employé figurant dans l'URL, sans faire de vérification plus poussée pour s'assurer que la personne qui modifie la fiche est cette même personne, et bien c'est très simple pour que moi, employé lambda, puisse modifier tes coordonnées à toi si je connais ton numéro d'employé : il suffit que j'indique ce numéro dans l'URL et hop, ni vu ni connu, maintenant tu habites Pétaouchnok.

JmL40 · 20/02/2008, 14h45

Citation:

il suffit que j'indique ce numéro dans l'URL et hop, ni vu ni connu, maintenant tu habites Pétaouchnok.

> Ceux à quoi je ne voudrait pas arriver car il y a pas mal de petits malins !

Sérieusement :

L'application ne concerne pas du personnel de l'entreprise mais plutot des données techniques que ces personnes la utilisent judicieusement pour diverses affaires (recherches,commercialisation ...).

Ces données sont parfaitements abstraites pour un utilisateur ne connaissant pas le domaine de l'entreprise (formule,sigle...). Cependant il y a tout de même un identifiant pour certains types de données qui lui doit être le moins visible et j'en viens justement à ta remarque sur le principe de vérifications des formulaires.

En effet, pas mal de mes formulaires utilisent cette identifiant unique (on va dire "NAME") et sont passe en POST.Chacunes de ces pages sont accessibles que si l'utilisateur s'est logué donc j'effectué une vérification par des variables de sessions pour accéder à cette page.
Ma question : Il y a toujours un risque ou bien ma technique est on va dire "passable" ?

Schéma : Formulaire > Post > Vérification Session > Résultat !

Merci de me soutenir dans mon combat ....

Cordialement

_Mac_ · 20/02/2008, 15h06

Oui, c'est très bien ça : les sessions sont assez difficiles à contourner donc si tu vérifies par rapport à des infos de session, c'est bien. Mais faut pas en abuser non plus car les sessions alourdissent pas mal les serveurs : tu peux faire passer des identifiants de produits dans les URL, etc. y a pas de souci en particulier parce que ce sont des infos plus "banales" que des numéros d'employés

Si tu veux limiter l'accès aux produits aux personnes par rapport à certains critères, laisse l'identifiant du produit dans l'URL mais quand on demande la page, utilise l'identifiant de l'utilisateur qui est en session pour vérifier qu'il a bien les droits sur le produit qu'il demande.

En fait, si l'appli est déjà développée, envisage uniquement des améliorations comme des vérifications supplémentaires : inutile de la réécrire.

JmL40 · 20/02/2008, 15h46

Citation:

laisse l'identifiant du produit dans l'URL mais quand on demande la page, utilise l'identifiant de l'utilisateur qui est en session pour vérifier qu'il a bien les droits sur le produit qu'il demande.

Hola ! C'est exactement l'opération que je fais, variable post, plus vérification session donc tout est bon.

Je te fais confiance vis à vis de la sécurité des variables de sessions

(rire!) ...
J'ai donc bien travaillé et bien réfléchit à mon problème (attention les chevilles

) .

Plus sérieusement, je te remercie de m'avoir suivis et d'avoir répondu à toutes mes demandes.

Sur ces mots, je me consacre à un autre boulot, un menus css facon explorateur windows

...

Bref bonne après-midi à toi et à bientot !

Cordialement

19/02/2008, 17h12	#1
JmL40 Membre actif Inscription : mai 2007 Messages : 310 Détails du profil Informations personnelles : Âge : 26 Informations forums : Inscription : mai 2007 Messages : 310 Points : 191 Points : 191	URL identiques sur chaque page ? Bonjour, Ayant développer une application web en PHP/MySQL, je souhaite la sécuriser au maximum. J'ai déjà résolu un premier niveau de sécurité qui a mon sens reste basique, à savoir l'accès direct à une page par saisie de l'url (ex : www.monsite.fr/page1.html). Dans mon cas, si l'utilisateur n'est pas "logué" et enregistré, celui-ci est automatiquement redirigé vers la page d'authentification. Bref, ce premier niveau de sécurité fonctionne parfaitement. Vous allez donc me dire mais pourquoi vouloir plus ?. D'une part pour apprendre, mais aussi pour avoir une application 100% fiable et sécurisée. So ? what's my probleme ! En d'autres termes, je souhaiterai que l'utilisateur qui consulte les différentes pages de l'application ne voit qu'un seul et unique URL par exemple, www.monsite.fr. www.monsite.fr serai visible tout au long de la consultation. J'ai donc fait des recherches sur le principe, les méthodes, j'ai consulté ce topic en premier : http://web.developpez.com/tutoriel/apache/urlrewriting/ J'ai réussi à mettre en oeuvre la première méthode, et échoué sur les suivantes. Cependant, tout cela ne correspond pas à mes attentes ... Je demande donc votre aide ! Merci à tous
	00

19/02/2008, 17h54	#2
_Mac_ Rédacteur/Modérateur Inscription : août 2005 Messages : 8 310 Détails du profil Informations forums : Inscription : août 2005 Messages : 8 310 Points : 8 592 Points : 8 592	Hello, Il y a 2 méthodes seulement pour toujours voir uniquement "http://www.tonsite.com/" dans la barre d'adresse : Utiliser des frames. C'est de très loin la méthode la plus simple Faire toute la navigation de ton site en POST : quand tu cliques sur un lien, en fait tu actives un JavaScript qui va poster un formulaire sur /index.php qui va renvoyer la page demander. C'est super lourd. 3 remarques à ce propos : Quelque soit la solution (surtout la 2ème quand même), l'indexation de ton site ne va pas être terrible Tes pages seront peu ou pas "bookmarkables" Limiter l'affichage de l'adresse n'a rien à voir avec la sécurité de ton site __________________ Du détail, du détail, du détail !!! Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
	00

20/02/2008, 10h55	#4
_Mac_ Rédacteur/Modérateur Inscription : août 2005 Messages : 8 310 Détails du profil Informations forums : Inscription : août 2005 Messages : 8 310 Points : 8 592 Points : 8 592	Sécuriser, c'est un bien grand mot : il veut dire quoi pour toi, exactement ? Sécuriser, c'est par exemple vérifier que son serveur ne présente pas de faille connue. Ca, c'est surtout si tu héberges toi-même ton site ou si tu es sur un serveur dédié, car si tu es hébergé mutualisé, c'est l'hébergeur qui est responsable de cette partie. Y a des outils genre Nessus pour faire un audit. Sécuriser, ça veut dire aussi s'assurer que son site (partie HTML/PHP, etc.) ne présente pas de défaut. Là, c'est beaucoup plus difficile à voir car c'est pas en cachant les URL ou en mettant une protection par login/mot de passe qu'on peut s'en prémunir La cible, c'est tous les scripts PHP de ton site, en particulier : les scripts d'upload : vérifier qu'on ne peut pas uploader un fichier contenant du code PHP par exemple et l'appeler ensuite. envoi de mail : vérifier qu'on ne peut pas forger un en-tête SMTP. Base de données : vérifier que son code n'est pas sensible à l'injection SQL. URL : ne pas y faire figurer les infos sensibles genre mots de passe, nom de script, etc. bref, tout ce qui pourrait tenter qq'1 de bricoler les URL. Y en a des tonnes d'autres, et là, à ma connaissance, y a pas d'outils automatiser pour vérifier tout ça Faut chercher sur le Web s'il y a des tutos ou des exemples de hack pour vérifier que ton site n'y est pas soumis. N.B. : je disais que masquer l'URL n'est pas une solution car il suffit de faire un clic droit + propriétés pour voir la vraie URL de la page. Dans tous les cas, si qq'1 veut attaquer ton site, il saura très bien forger les URL qui l'intéressent. __________________ Du détail, du détail, du détail !!! Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
	00

20/02/2008, 13h32	#6
_Mac_ Rédacteur/Modérateur Inscription : août 2005 Messages : 8 310 Détails du profil Informations forums : Inscription : août 2005 Messages : 8 310 Points : 8 592 Points : 8 592	Si c'est en intranet, y a moins de risques de piratage (enfin, on peut espérer). Y a surtout 2 choses à voir pour ton cas : s'assurer que les formulaires vérifient bien ce qu'on envoie (point que j'ai oublié de mentionner). Par exemple, tu as un champ qui attend un entier. Faire une vérif en JavaScript, c'est bien, mais il faut aussi que le serveur fasse la vérification. Idem pour les zones de texte qui servent ensuite à un affichage : au moment de l'affichage, il faut bien penser à encoder en HTML la chaîne à afficher, ce afin d'éviter que les éventuelles balises <script> ou autre ne soient interprétées par le navigateur à l'affichage. Les URL : éviter comme je disais de mettre des trucs trop sensibles dans les URL comme des noms (de personne), des identifiants trop évidents (par exemple, numéro d'employé) ou des noms de fichiers. Le coup du numéro d'employé, tout dépend de ce pour quoi tu l'utilises mais pas exemple, si ton appli est un truc qui permet à tous les individus de la boîte de modifier leurs coordonnées personnelles, et si la page qui affiche le formulaire s'appuie uniquement sur le numéro d'employé figurant dans l'URL, sans faire de vérification plus poussée pour s'assurer que la personne qui modifie la fiche est cette même personne, et bien c'est très simple pour que moi, employé lambda, puisse modifier tes coordonnées à toi si je connais ton numéro d'employé : il suffit que j'indique ce numéro dans l'URL et hop, ni vu ni connu, maintenant tu habites Pétaouchnok. __________________ Du détail, du détail, du détail !!! Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
	00

20/02/2008, 15h06	#8
_Mac_ Rédacteur/Modérateur Inscription : août 2005 Messages : 8 310 Détails du profil Informations forums : Inscription : août 2005 Messages : 8 310 Points : 8 592 Points : 8 592	Oui, c'est très bien ça : les sessions sont assez difficiles à contourner donc si tu vérifies par rapport à des infos de session, c'est bien. Mais faut pas en abuser non plus car les sessions alourdissent pas mal les serveurs : tu peux faire passer des identifiants de produits dans les URL, etc. y a pas de souci en particulier parce que ce sont des infos plus "banales" que des numéros d'employés Si tu veux limiter l'accès aux produits aux personnes par rapport à certains critères, laisse l'identifiant du produit dans l'URL mais quand on demande la page, utilise l'identifiant de l'utilisateur qui est en session pour vérifier qu'il a bien les droits sur le produit qu'il demande. En fait, si l'appli est déjà développée, envisage uniquement des améliorations comme des vérifications supplémentaires : inutile de la réécrire. __________________ Du détail, du détail, du détail !!! Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute
	00

20/02/2008, 08h34	#3
JmL40 Membre actif Inscription : mai 2007 Messages : 310 Détails du profil Informations personnelles : Âge : 26 Informations forums : Inscription : mai 2007 Messages : 310 Points : 191 Points : 191	Bonjour, Tes remarques ont bien été prise en compte, tout cela reste sommaire dans ce cas la. Doit-je donc m'en tenir à mon premier niveau de sécurité ou vous me conseillez une autre solution toujours au niveau de la sécurité? A vrai dire, je veux sécuriser un maximum mon application, que puis-je employer comme méthode encore ? Merci pour ton explication ! Cordialement
	00

20/02/2008, 12h17	#5
JmL40 Membre actif Inscription : mai 2007 Messages : 310 Détails du profil Informations personnelles : Âge : 26 Informations forums : Inscription : mai 2007 Messages : 310 Points : 191 Points : 191	Merci pour tes explications claires. En fait, je pense oublier cette méthode car comme tu le dis "tout est possible" ! En somme je vais donc établir une liste de points a vérifier sur l'ensemble de mon application, noms des variables, fichiers uploads, formulaires et autres. Cette vérification me permettra de réduire au maximum les risques ... Pour finir, et pour répondre à ta question, la sécurite pour moi dans cette application se résume à cette idée : > Gérer & eviter les éventuelles erreurs provoquées par les utilisateurs (en spécifiant une page par url par exemple) par différentes actions, sachant que ces utilisateurs sont novices. (Précisons que l'application est en intranet) Voila merci pour tout ! Cordialement ps: Je test actuellement Nessus ...
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email