[Sécurité] Sécurité totale pour un espace membre [Débat]

**Sub0** · 01/06/2004, 17h07

Salut!

Je dois réaliser pour une société d'hébergement de site internet, un formulaire "partie membre", avec inscription, identification, connexion automatique (cookie), etc... Le tout grâce au PHP et une base de donnée MySQL. Une fois logé, le membre peux obtenir et modifier ses informations perso...

Je voulais utiliser au départ les variables de session, mais j'ai lu sur le net, qu'il y avait des risques que d'autres personnes puissent récupérer des infos juste en modifiant l'ID de session... Je cherche un système fiable au maximum... et/ou peut-être l'améliorer...

J'ai besoin de vous pour me guider, merci!

**mathieu** · 01/06/2004, 17h22

si tu veux un petit plus pour la sécurité, enregistre dans ta session, l'adresse IP ou la signature du navigateur (ou les deux

) et tu auras un meilleur niveau de sécurité

ensuite tu peux aussi modifier le nom de cookie de session mais ce renseignement s'obtient rien qu'en se connectant donc ce n'est pas indispensable

**Koo** · 01/06/2004, 20h08

dejà, rien n'est jamais secure à 100%

les sessions si tu crypte ca devrait pas poser de prob, surtout sur un serveur SSL

tu peu aussi completer avecune authentification par IP, que tu stocke dans une BDD (et qui expire au bout d'un certain temps)

ou encore utiliser l'authentification HTTP

register_globals = off est obligatoire pour une bonne sécurité. Tu peut aussi désactiver l'affichage des erreurs, après la phase de developpement : error_reporting(0)

jete aussi un coup d'oeil sur des projet connus :

http://www.mamboserver.com/
http://www.oscommerce.com/
...

**Sub0** · 02/06/2004, 00h11

Envoyé par m@

...les variables de sessions sont fiables quand elles sont utillisées avec HTTPS

Je vais me renseigner...

Envoyé par KoO

dejà, rien n'est jamais secure à 100%

Je n'adère pas, car ce n'est pas justifié pour le moment!

Envoyé par KoO

ou encore utiliser l'authentification HTTP

C'est à dire?

Envoyé par KoO

register_globals = off est obligatoire pour une bonne sécurité. Tu peut aussi désactiver l'affichage des erreurs, après la phase de developpement : error_reporting(0)

Oui, ça c'est prévu depuis le début...

Envoyé par KoO

jete aussi un coup d'oeil sur des projet connus :
http://www.mamboserver.com/
http://www.oscommerce.com/

Trop de choses m'échappent pour que ces systèmes me semblent sécurisés! Bien au contraire!
Quant à oscommerce... : http://www.oscommerce-fr.info/forum/...hp/t22391.html

Merci d'avance.

**Koo** · 02/06/2004, 09h27

Envoyé par Sub0

Envoyé par KoO

dejà, rien n'est jamais secure à 100%

Je n'adère pas, car ce n'est pas justifié pour le moment!

Moi on ma tjs dis en cours d'admin rezo, qu'un pc secure, c'est un pc éteint, sans clavier/souris/connection, coulé dans un bloc de béton au fond de l'atlantique

Envoyé par Sub0

Envoyé par KoO

ou encore utiliser l'authentification HTTP

C'est à dire?

http://www.php.net/manual/fr/features.http-auth.php

quand à oscommerce, c'est sur que ya des failles, vu l'usine à gaz que c'est, mais tout ne doit pas être à jeter.

deux autres trucs importants je pense :
si tu n'est pas en HTTPS, tu peut faire crypter les données que le client tenvoie depuis un formulaire, avec une fonction JavaScript (md5). Ainsi, tu n'as plus (moins) de problèmes d'interception des variables $_POST

suspendre les comptes un certain temps, après plusieurs echecs d'auth

m@ · 02/06/2004, 14h44

si tu n'est pas en HTTPS, tu peut faire crypter les données que le client tenvoie depuis un formulaire, avec une fonction JavaScript (md5). Ainsi, tu n'as plus (moins) de problèmes d'interception des variables $_POST

cool et pour décrypter le md5, une idée ?
remarque, c'est vrai que niveau interception, t'es plutôt protégé !

sinon, pour l'auth HTTP, les infos transitent en clair, et sont à la portée de n'importe quel sniffer, idem d'ailleurs pour les cookies et les vars de session.
si ton site est réellement sensible HTTPS est indispensable

**doof** · 02/06/2004, 15h33

Un https maison est impossible pour la raison simple que le browser devrat decrypter ce qui arrive, il faut donc qu'il connaisse déjà le protocole et qu'un algo soit impléménté.

m@ · 02/06/2004, 15h37

à chacun ses idées fixes...

alors re :

1. ton code ne sera probablement pas aussi fiable
2. tu ne pourras pas décrypter les données, et les comparer n'est pas par exemple pas applicable pour rentrer une quantité, etc$
3. tu ne pourras pas crypter toute ta page puique comme le dit doof, le browser ne connaît pas le protocole.
4.en particulier toutes les infos HTTP (sessions, cookies...) sont en clair

bien sûr tu peux les crypter, mais le problème reste le même :

1. ou tu les hashes et elles sont indécryptables
2. ou tu les cryptes avec un algo maison potentiellement foireux
3. ou tu te sers d'une solution pro et retour à HTTPS et co

j'en profite pour rajouter un ptit mot sur le Security Through Obscurity qui regroupe toutes les pratiques consistant à brouiller les traces par des bidouilles, dissimuler le code source, etc... et dans lequel je range aussi les algos de crypt amateurs pour lesquels, (mais ne l'aurez vous pas compris ?) je n'ai pas beaucoup d'estime.
de façon générale, un tel comportement de la part d'un développeur entraîne 3 conséquences.

1. Illusion de sécurité, car "personne n'est au courant"
2. Découverte de failles facilitée par l'absence de travaux d'experts sur la méthode utilisée
3. en cas de découverte de faille, ralentissement du processus de patch, car peu de monde en a les compétences et le recul nécessaire.

à contrario, des standards tels que SSL profitent d'une grande réactivité, car ils sont par définition publics et qu'un très grand nombre de personne les ont étudié et ont les compétences pour trouver et patcher les failles.

cordialement

PS : moi aussi je le verrais bien en POST-IT ce ti topic

**matN59** · 02/06/2004, 23h10

bonjour a tous,

je me permets de faire un peu de pub mais j'ai realisé un tuto sur la secu des appli web http://www.phplibrairies.com/index.p...1&tutorial=107
cela pourra peut etre aider un peu le sujet de ce topic

Envoyé par KoO

ou encore utiliser l'authentification HTTP

en ce qui concerne l'authentification http, et bien c'est une methode qui craint tout simplement parce que par defaut les mots de passent circulent en clair. C'est a dire que dans le cas d'une attaque de type man in the middle, avec un sniffer, on peut recuperer le mot de passe.
L'autre mode dit securisé d'auhthenfication http ne l'est pas: le mot de passe est encodé, mais il est rebalancé encodé et c'est la version encodé qui est verifié; cela revient au meme puisque un man in the middle qui sniffe les trames et qui recupere le mot de passe - encrypté - peut le rebalancer au serveur et de ce fait s'authentifier s'en avoir a connaitre le pass.
donc faut laisser tomber l'authentification http si vous vouler faire un truc sur

**Koo** · 03/06/2004, 09h19

Envoyé par ermelir

le mot de passe est encodé, mais il est rebalancé encodé et c'est la version encodé qui est verifié

Gnii ???

je pensai pas que l'auth HTTP etait si passoire, mais si ske tu dis est vrai, jme demande par exemple, pk les developpeur de PhpMyAdmin on fait le choix de cette authentification.

Exemple sur free :
Je me logue sur PMA pour administrer MySql. Quelqu'un au milieu sniff les paquets. Y recupere mon login/mdp. Pouf, il a accès à mon mail + FTP + mysql (vu ke les login/mdp c les memes. Pis la meme chose est possible avec le FTP).

**doof** · 03/06/2004, 10h00

Oui, si l'on recupere les paquets, on peut choper le mdp, la seule technique qui encode les paquets, c'est justement https.

Si phpmyadmin à retenu cette méthode, c'est que peu de serveurs sont en https, et qu'ils ont du juger que c'est plus sur qu'une protection par sessions (aucune faille niveau programmation). de plus, celà n'empeche pas d'utiliser phpmyadmin en https.

**matN59** · 03/06/2004, 11h40

Le seul reproche que l'on peut faire a l'authentification https, c'est que bien que la communication soit cryptée, elle n'authentifie pas que le client soit bien le client escompté ( a moins bien sur que le client ait un certificat, mais vu le tarif, j'en doute

)

m@ · 03/06/2004, 16h12

*les puristes de la métaphore vont me tomber dessus, mais en gros on peut assimiler https à un tunnel inviolable entre un ordinateur A et un ordinateur B. tout ce qui part de A arrive sans possibilité de détournement ou de corruption en B.

(ne lisez pas ça si vous êtes déjà perdu : un serveur peut acheter un certificat SSL, qui est certifié par une autorité indépendante assurant que ce serveur B appartient bien à telle société ; pour reprendre l'image, on sait donc avec sûreté, où arrive le tunnel)

*après rien n'authentifie A qui peut très bien être un méchant pirate. c'est là qu'est nécessaire l'auth par mot de passe, que ce soit via HTTP ou autre.
en effet même si les mots de passe ne sont pas cryptés par HTTP, ils voyagent en toute sécurité dans notre "tunnel" HTTPS

*quant'aux personnes ne pouvant pas utiliser HTTPS, cela sous entend que vous ne disposez pas de serveur dédié, etc... et donc que votre projet n'est pas d'une importance exceptionnelle, qu'il ne contient pas d'infos particulièrement sensibles, et qu'il ne vas pas attirer 75% des hackers de la planète.
dans ce cas, il semble raisonnable de se baser sur une authentification en clair, de stocker les mots de passe cryptés sur le serveur et d'éduquer vos utilisateurs à en changer souvent.

cordialement

**Sub0** · 04/06/2004, 04h45

Salut! Merci à tous pour vos réponses!

J'ai mis le topic en post-it... Je fais le point de la situation:

Veuillez confirmer svp :

1) Mon développement est destiné à un hébergeur de site et celui-ci possède sa propre salle blanche. Il devra utiliser le module SSL d'Appache, seulement j'imagine qu'il devra payer une licence...
2) De mon côté, je n'aurai rien de particulier à faire , la seule différence se situera au niveau l'URL des pages qui commenceront par "https://" au lieu de "http://"...
3) Une fois cela en place, j'aurai donc la garantie que toutes les informations qui transiteront entre les serveurs et les utilisateurs ne pourront-être interceptées et/ou décryptées par qui que ce soit...

Grâce au JavaScript et au PHP, je peux déjà récupèrer quelques informations sur le visiteur : IP, host, port, proxy, navigateur, etc... Ces informations permettront une 1ère identification sans avoir à réclamer le mot de passe du membre. Je pensais utiliser ce système pour remplacer le cookie. Dans le cas d'un doute sur l'identité du membre, celui-ci devra s'identifier... Lorsque un certain nombre consécutif d'identifications auront échoué, l'accès du compte sera bloqué et un mail sera envoyé au support technique pour signaler le compte bloqué, ceci afin d'éviter que quelqu'un puisse obtenir l'accès par "force-brute"...
4) Qu'en pensez-vous?

Autrement, le membre sera logé. Il pourra alors accèder à ses informations et les modifier. Pour que le membre puisse visiter une page ou bien remplir un formulaire, j'ai besoin de son login en paramètre de l'URL, pour pré-renseigner les champs de saisie par exemple... Je rècupère le pseudo et le mot de passe qui se trouvent dans l'URL avec $_GET. Ces 2 informations seront légèrement encodées et passées de page en page...
5) Y'a-t-il un danger quelconque à cela?

Merci de votre aide!

m@ · 04/06/2004, 10h10

1.ton hébergeur ne devra pas payer l'utilisation du module SSL mais un certificat, c'est à dire que son serveur sera identifié de façon fiable comme étant celui de sa société et non celui d'un pirate.

2.le couple (IP,port) identifie un visiteur de façon unique. toutefois, il peut évoluer avec le temps, ce qui risque de compliquer le suivi de ton visiteur. mieux vaut demander le mot de passe et se servir après des variables de sessions (plutôt que de les passer par URL) ; pas besoin de les encoder.

3.enfin, il vaut mieux éviter de bloquer un compte après des échecs, il est préférable de temporiser avant d'autoriser un nouvel esai. imagine sinon la facilité qu'aurait n'importe qui à paralyser ton serveur.

4. je me propose sur le weekend de reprendre me docs et d'écrire un petit article récapitulatif sur le sujet.
l'idée vous semble-t-elle intéressante ?
quels points souhaiteriez-vous voir traiter ?

**Koo** · 04/06/2004, 10h25

1) pour la licence ca depend tu type d'appli que tu utilise. Dans un cadre non-commercial, tu peu utiliser par exemple open ssl. Par contre, il faudra toujours banquer, pour obtenir un certificat SSL.

2) exact. Une config d'apache est aussi possible, pour redirigier une page appelée en http, vers https

4) baser l'authentification uniquement sur l'IP est dangereux. Un spoof d'IP est toujours en visageable. Par contre avec ip + host + ..., j'en sais rien, mais personnelement j'éviterait (ou à utiliser juste en complément).

Pour le bloquage du compte, ca peut avoir un effet pervers, comme m@ la souligné.

5) ca devrait pas poser de prob. Par contre comme komme lavais dis plus haut, tu riske de te faire chier à repasser les parametres par url. Les sessions sont moins contraignantes.

Je rajouterait 2 trucs :
1 - la sécurité depend de skon à a protéger. Pour un site perso, un mdp crypté dans la base devrait suffir. Pour un site e-commerce, vaut mieu blinder.
2 - c'est tjs le maillon le plus faible qui lache. Ca sert à rien d'etre en https, si par exemple un injection SQL est possible (quand on utilise pas addslashes devant les variable post/get ...)

**mathieu** · 04/06/2004, 10h44

Envoyé par KoO

1 - la sécurité depend de skon à a protéger. Pour un site perso, un mdp crypté dans la base devrait suffir. Pour un site e-commerce, vaut mieu blinder.

ca coute pas grand chose d'enregistrer l'adresse IP et le navigateur dans des variables de sessions et de vérifier qu'il n'y a pas de modification même si c'est utilisé pour un petit site perso
d'ailleurs je vais de ce pas rajouter cette protection dans ma classe d'identification et ce soir je poste ici les propriétés que j'ai utilisé

**Sub0** · 04/06/2004, 11h34

Salut Mathix! Bonjour à tous!

Effectivement, l'enregistrement des informations IP, host, port, proxy, type de la machine, navigateur, plugins, résolution d'écran, etc... sont en compléments de l'identification. Si certains de ces paramètres changent, une identification sera réclamée. Ainsi, j'évite d'utiliser un cookie. Ces informations serviront aussi de support au service technique pour le dépannage...

Au niveau des variables de sessions, pouvez-vous me dire quelles sont les fonctions qui sont vraiment indispensables? Dois-je leur donner une date limite de validité? etc...

J'ai lu quelque part sur la toile, qu'il est possible de récupérer les données d'autres membres en utilisant l'ID de la session... Qu'en pensez-vous au juste?

Merci de votre aide!

**Koo** · 04/06/2004, 14h49

pour plus d'infos suffit de regarder la doc officielle, rubrique Sessions et sécurité
http://www.php.net/manual/fr/ref.session.php

ya un lien fort interesssant (anglish)

m@ · 04/06/2004, 16h01

je pense quand même qu'il vaut mieux éviter de trop compliquer...
plus c'est simple moins il y a de risque d'avoir une faille.
un utilisateur qui donne le bon mot de passe est le bon utilisateur point.
et si quelqu'un réussit à intercepter le mot de passe, il est très probablement capable de transmettre les bones infos de navigateur, ip...

...sinon, pour mon récapitulatif, je pense parler de :
1. formulaires
2. https
3. cookies/sessions
4. stockage des mots de passe
5. éduquer les utilisateurs
6. bidouilles
d'autres idées

:

[Sécurité] Sécurité totale pour un espace membre [Débat]

Langage PHP

Discussions similaires

Partager

Partager