|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Membre habitué
![]() Inscription : septembre 2005 Messages : 514 ![]() |
Bonjour,
je suis en train de réaliser un site pour un ami. Cet ami qui n'est pas informaticien aura besoin d'un espace client pour partager des fichiers avec ses clients. Cet espace devra être très simple d'utilisation et ne pas demander des milliers de manip pour ajouter un fichier. Autre condition, sur le serveur hébergeant le site, je n'ai pas droit aux htaccess. Ces fichiers étant pour certains assez critiques (devis, factures...) je voudrais m'assurer en postant ici que je ne faillis pas aux règles de sécurité de base. Voici donc comment j'envisage cet espace client protégé : Voici d'abord l'architecture des répertoires : racine > fichiers du site sous-rép 1 > sous-rép 2 > dossier client 1 > fichier 1 client 1.doc fichier 2 client 1.doc dossier client 2 > dossier client 3 > Sécurité 1 : Je place un fichier index.html dans les sous-répertoires : sous-rep1 et sous-rep2 afin que le contenu de ceux-ci ne soit pas lisible directement. Sécurité 2 : L'accès a un espace client se fait par identification qui ouvre une session pour le client Les fichiers à partager sont des fichiers type word, excel que le client devra pouvoir télécharger directement. Donc je ne peux pas interdire aux fichiers un accès direct (et de toutes façons, je n'ai droit aux htaccess) Sécurité 3 : Pour ne pas que l'adresse soit visible directement le fichier sera téléchargeable via un script de type : download.php?id=x. Ce script récupèrera l'adresse réelle du fichier via une base de données et lancera le téléchargement du fichier via une fonction de download utilisant la fonction PHP header Sécurité 4 : Pour la fonction download, je vérifie que le HTTP_REFERRER est bien la page d'accueil de l'espace client afin qu'on soit obligé de lancer ce script de téléchargement du fichier depuis le site. De plus avant de lancer la fonction de download, je vérifie que le client dont la session est ouverte a bien droit d'accéder au fichier qu'il tente de télécharger (pour éviter les manipulations sur l'url : download.php?id=x, en changeant le x pour accéder à d'autres fichiers d'autres espaces par exemple) Voilà... Ainsi mon ami n'aura qu'a créer ses dossiers clients, mettre les fichiers correspondants dedans et lancer un script qui permettra de faire la correspondance entre les fichier et un numéro identifiant (le x de mon url) Que pensez-vous de cela ? voyez-vous des failles de sécurité quelque part ? Me suis-je suffisemment protégé ? Merci de vos avis... |
|
|
00
|
|
|
#2 | ||||
|
Membre émérite
![]() ![]() Michaël Conseil - Consultant en systèmes d'information Inscription : juin 2003 Messages : 673 ![]() |
Citation:
Citation:
Citation:
Citation:
Sinon grosso modo, ca m'a l'air bien. Dommage pour le htacess
__________________
Michaël Mary Consultant PLM dans une société de conseil toulousaine Auditeur CNAM-IPST depuis septembre 2008 "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods mon cv et mon domaine et mon blog Aucune question technique par MP, svp |
||||
|
00
|
|
|
#3 |
|
Membre habitué
![]() Inscription : septembre 2005 Messages : 514 ![]() |
Merci pour ta réponse...
je crypte les mots de passe via md5. Et pour l'identification je fas un truc du genre : select count(id) from utilisateur where login='$login' and password = 'md5($password)' sachant que login et password seront les valeurs transmises par formulaire lors de l'identification de l'utilisateur. Je pourrai ajouter une image afin d'éviter les robots spammeurs ou un test sur l'ip pour limiter le nombre d'essais. Concernant la session, la fonction de download vérifiera que l'utilisateur dont la session est ouverte a possibilité de télécharger le fichier dont id=x. La fonction de download s'exécutera depuis un popup ouvert depuis la page qui liste les fichiers du dossier client. Ainsi via un http_referrer, je pourrai vérifier qu'on accède au download uniquement via la page réservée au client. En revanche quand tu parles de vérifier l'intégrité de la session, à quoi fais-tu référence ? Merci encore |
|
|
00
|
|
|
#4 |
|
Membre émérite
![]() ![]() Michaël Conseil - Consultant en systèmes d'information Inscription : juin 2003 Messages : 673 ![]() |
Fais attention aux injections SQL... Fais un test du contenu en échapant les caractès spéciaux.
Aussi, je te conseille une recherche sur google sur le thème de tests de sécurité PHP Portals. J'ai déjà vu des sites proposant des batteries de tests quxquels on ne pense pas au premier abord. Validité de session => empêche l'enregistrement des identifiants par le browser.
__________________
Michaël Mary Consultant PLM dans une société de conseil toulousaine Auditeur CNAM-IPST depuis septembre 2008 "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods mon cv et mon domaine et mon blog Aucune question technique par MP, svp |
|
00
|
|
|
#5 |
|
Membre habitué
![]() Inscription : septembre 2005 Messages : 514 ![]() |
heu c'est peut être moi qui suit un peu lent mais je vois toujours pas de quoi tu parles lorsque tu dis : Validité de session => empêche l'enregistrement des identifiants par le browser.
|
|
|
00
|
|
|
#6 |
|
Membre émérite
![]() ![]() Michaël Conseil - Consultant en systèmes d'information Inscription : juin 2003 Messages : 673 ![]() |
Je me suis mal exprimé. En gros, n'autorise aucun enregistrement des informations de session => tu n'utilises pas de cookies qui enregistre ces enfo n'est-ce-pas ?
Pour résumer : c bien ce que tu as fait mais fais bien attention que tu sois bien obligé de passer par la phase d'enregistrement de l'utilisateur pour chaque connection au site.
__________________
Michaël Mary Consultant PLM dans une société de conseil toulousaine Auditeur CNAM-IPST depuis septembre 2008 "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods mon cv et mon domaine et mon blog Aucune question technique par MP, svp |
|
00
|
|
|
#7 |
|
Membre habitué
![]() Inscription : septembre 2005 Messages : 514 ![]() |
OK, je comprends, merci...
En effet, pour ce genre d'application, je n'utilise pas de Cookies, mais les sessions de base : session_start(); $_SESSION['iduser'] = ... ; unset($_SESSION); Encore merci pour tes conseils !!! |
|
|
00
|
|
|
#8 |
![]() ![]() Marc ChappuisDéveloppeur Web Inscription : décembre 2003 Messages : 1 535 ![]() |
Salut,
ton modèle de sécurité me semble pas trop mal, mais je te déconseil de travailler avec le http_referer pour deux raisons. 1) c'est facilement "spoofable" vu que c'est un en-tête http 2) certains firewall locaux le fitre abusivement (pour des sois-disant raisons de confidentialités), tu risque donc d'avoir des utilisateurs qui ne t'envoie jamais de http_referer on est bien d'accord que ta page download.php va lire le fichier et le renvoyer au client (avec readfile par exemple), et surtout pas faire un redirect sur l'url réel du fichier ? en dernier lieu, je ferai en sorte que le paramètre "id" ne soit en aucun cas un numéro consécutif, pour qu'il soit impossible de "deviner" les autres id existants. Une technique simple consiste a ajouter un random à l'id, par exemple: id=12-1244324 12 représente l'id du fichier, et 1233324 un nombre aléatoire sauvé dans la db pour ce fichier. Ainsi, celui qui essaie l'id 13-1233324 aurra un random faux pour le fichier 13 en dernier lieu il faudrait que le nom des dossier clients soit aussi "compliqué" par exemple, le dossier du client 22 pourrait être nommé cli-22-2232312312 aussi composé d'un nombre aléatoire en suffix. même chose pour les fichiers sauvés.
__________________
Si ton code fait plus d'une ligne, c'est que tu as mal choisi ton langage ! |
|
|
00
|
|
|
#9 |
|
Membre confirmé
![]() |
pourquoi ne pas executer le script de telechargement par le biais de la methode post (on ne voit pas l'url), il suffit de fait un petit formulaire avec un bouton telecharger par exemple.
bien sur on peut aller dans le code pour voir quel script est utilisé, mais bon c'est encore un peu mieux ... ou alors utiliser du flash ...
__________________
Venez voir par là... |
|
|
00
|
|
|
#10 |
|
Membre chevronné
![]() Développeur Web Inscription : décembre 2004 Messages : 636 ![]() |
Si ton souci est la sécurité, alors cette méthode de cacher les urls des fichiers avec des urls de scripts, c'est plutôt "léger" niveau sécurité.
En effet, tous les fichiers sont accessibles par http, donc en trouvant leur url, on peut les chopper sans authentification. Si ces fichiers contiennent des informations sensibles sur les clients (informations personnelles sur les employés, informations comptables, stratégiques etc ...), il faudra que ton ami croise les doigts pour que personne ne se rendent jamais compte de cette faiblesse très facile à exploiter, sinon en cas de problème ses clients pourraient se retourner contre lui (sans parler du déficit d'image pour sa boite). Si ces fichiers sont sensibles, toutes tes mesures sont de bonnes idées mais c'est très loin d'être suffisant. Voici, à mon avis, les deux solutions les plus simples qui permettraient d'améliorer la sécurité : - soit changer d'hébergeur pour un qui permet de faire du htaccess - soit stocker les fichiers directement dans la base de données ... je sais c'est pas très "beau" mais ça sera beaucoup plus sûr, et ton ami pourra dormir tranquille au moins
__________________
Ne cliquez pas sur ce lien |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com