Publicité
+ Répondre à la discussion
Page 1 sur 10 12345 ... DernièreDernière
Affichage des résultats 1 à 20 sur 197
  1. #1
    Expert Confirmé
    Avatar de Sub0
    Homme Profil pro
    Développeur Web
    Inscrit en
    décembre 2002
    Messages
    3 516
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : décembre 2002
    Messages : 3 516
    Points : 3 639
    Points
    3 639

    Par défaut [Sécurité] Sécurité totale pour un espace membre

    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!

  2. #2
    Expert Confirmé Sénior
    Avatar de mathieu
    Inscrit en
    juin 2003
    Messages
    5 038
    Détails du profil
    Informations forums :
    Inscription : juin 2003
    Messages : 5 038
    Points : 8 481
    Points
    8 481

    Par défaut

    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

  3. #3
    Koo
    Koo est déconnecté
    Membre du Club Avatar de Koo
    Inscrit en
    avril 2004
    Messages
    76
    Détails du profil
    Informations forums :
    Inscription : avril 2004
    Messages : 76
    Points : 67
    Points
    67

    Par défaut

    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/
    ...

  4. #4
    Expert Confirmé
    Avatar de Sub0
    Homme Profil pro
    Développeur Web
    Inscrit en
    décembre 2002
    Messages
    3 516
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : décembre 2002
    Messages : 3 516
    Points : 3 639
    Points
    3 639

    Par défaut

    Citation Envoyé par m@
    ...les variables de sessions sont fiables quand elles sont utillisées avec HTTPS
    Je vais me renseigner...

    Citation Envoyé par KoO
    dejà, rien n'est jamais secure à 100%
    Je n'adère pas, car ce n'est pas justifié pour le moment!

    Citation Envoyé par KoO
    ou encore utiliser l'authentification HTTP
    C'est à dire?

    Citation 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...

    Citation 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.

  5. #5
    Koo
    Koo est déconnecté
    Membre du Club Avatar de Koo
    Inscrit en
    avril 2004
    Messages
    76
    Détails du profil
    Informations forums :
    Inscription : avril 2004
    Messages : 76
    Points : 67
    Points
    67

    Par défaut

    Citation Envoyé par Sub0
    Citation 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

    Citation Envoyé par Sub0
    Citation 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

  6. #6
    m@
    m@ est déconnecté
    Membre confirmé
    Avatar de m@
    Inscrit en
    janvier 2004
    Messages
    143
    Détails du profil
    Informations forums :
    Inscription : janvier 2004
    Messages : 143
    Points : 244
    Points
    244

    Par défaut

    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

  7. #7
    Membre confirmé
    Avatar de doof
    Inscrit en
    août 2003
    Messages
    159
    Détails du profil
    Informations forums :
    Inscription : août 2003
    Messages : 159
    Points : 248
    Points
    248

    Par défaut

    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é.

  8. #8
    m@
    m@ est déconnecté
    Membre confirmé
    Avatar de m@
    Inscrit en
    janvier 2004
    Messages
    143
    Détails du profil
    Informations forums :
    Inscription : janvier 2004
    Messages : 143
    Points : 244
    Points
    244

    Par défaut

    à 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

  9. #9
    Membre régulier
    Homme Profil pro Matthieu
    Consultant informatique
    Inscrit en
    janvier 2003
    Messages
    134
    Détails du profil
    Informations personnelles :
    Nom : Homme Matthieu
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : janvier 2003
    Messages : 134
    Points : 74
    Points
    74

    Par défaut

    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
    Citation 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

  10. #10
    Koo
    Koo est déconnecté
    Membre du Club Avatar de Koo
    Inscrit en
    avril 2004
    Messages
    76
    Détails du profil
    Informations forums :
    Inscription : avril 2004
    Messages : 76
    Points : 67
    Points
    67

    Par défaut

    Citation 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).

  11. #11
    Membre confirmé
    Avatar de doof
    Inscrit en
    août 2003
    Messages
    159
    Détails du profil
    Informations forums :
    Inscription : août 2003
    Messages : 159
    Points : 248
    Points
    248

    Par défaut

    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.

  12. #12
    Membre régulier
    Homme Profil pro Matthieu
    Consultant informatique
    Inscrit en
    janvier 2003
    Messages
    134
    Détails du profil
    Informations personnelles :
    Nom : Homme Matthieu
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : janvier 2003
    Messages : 134
    Points : 74
    Points
    74

    Par défaut

    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 )
    blog : http:blog.kyp.fr

  13. #13
    m@
    m@ est déconnecté
    Membre confirmé
    Avatar de m@
    Inscrit en
    janvier 2004
    Messages
    143
    Détails du profil
    Informations forums :
    Inscription : janvier 2004
    Messages : 143
    Points : 244
    Points
    244

    Par défaut

    *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

  14. #14
    Expert Confirmé
    Avatar de Sub0
    Homme Profil pro
    Développeur Web
    Inscrit en
    décembre 2002
    Messages
    3 516
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : décembre 2002
    Messages : 3 516
    Points : 3 639
    Points
    3 639

    Par défaut

    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!

  15. #15
    m@
    m@ est déconnecté
    Membre confirmé
    Avatar de m@
    Inscrit en
    janvier 2004
    Messages
    143
    Détails du profil
    Informations forums :
    Inscription : janvier 2004
    Messages : 143
    Points : 244
    Points
    244

    Par défaut

    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 ?

  16. #16
    Koo
    Koo est déconnecté
    Membre du Club Avatar de Koo
    Inscrit en
    avril 2004
    Messages
    76
    Détails du profil
    Informations forums :
    Inscription : avril 2004
    Messages : 76
    Points : 67
    Points
    67

    Par défaut

    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 ...)

  17. #17
    Expert Confirmé Sénior
    Avatar de mathieu
    Inscrit en
    juin 2003
    Messages
    5 038
    Détails du profil
    Informations forums :
    Inscription : juin 2003
    Messages : 5 038
    Points : 8 481
    Points
    8 481

    Par défaut

    Citation 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é

  18. #18
    Expert Confirmé
    Avatar de Sub0
    Homme Profil pro
    Développeur Web
    Inscrit en
    décembre 2002
    Messages
    3 516
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : décembre 2002
    Messages : 3 516
    Points : 3 639
    Points
    3 639

    Par défaut

    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!

  19. #19
    Koo
    Koo est déconnecté
    Membre du Club Avatar de Koo
    Inscrit en
    avril 2004
    Messages
    76
    Détails du profil
    Informations forums :
    Inscription : avril 2004
    Messages : 76
    Points : 67
    Points
    67

    Par défaut

    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)

  20. #20
    m@
    m@ est déconnecté
    Membre confirmé
    Avatar de m@
    Inscrit en
    janvier 2004
    Messages
    143
    Détails du profil
    Informations forums :
    Inscription : janvier 2004
    Messages : 143
    Points : 244
    Points
    244

    Par défaut

    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 :

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •