Discussion :

[JmL40]

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_]

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]

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_]

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]

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_]

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.