Bonjour, je me suis lancé dans la prog web (j'ai horreur de ça mais c'est surement parceque je manque cruellement de pratique, pour être franc je me suis lancé dans une petite gestion d'utilisateurs, pour mettre un peu les mains dans le cambouis
Ca marche, par contre je me demande si c'est vraiment sécurisé ?
 
En gros l'utilisateur se connecte sur une page où il fournit son identifiant et mot de passe, puis il arrive ici :

 
et ensuite pour chaque page que je veux protéger je mets cet entête :
 

 
et pour se déconnecter :
 

 
soyez indulgents
qu'est ce qui pourrait être source d'ennuis dans ce genre de code ?
Merci

Ca m'interesse aussi.

au niveau de :  
$retour = mysql_query('SELECT pass FROM connect_table WHERE login LIKE "' . $id . '"');
on pourrait facilement faire une sql injection  
en mettant du SQL dans le champ du login on pourrait faire n'importe quoi ici.
donc un simple :  
mysql_real_escape_string($id) pourrait t'être utile

merci c'est exactement le genre d'infos que j'attendais
 
à titre informatif, que pourrait injecter l'utilisateur dans $id qui ferait foirer ma requête ?  
parceque je comprend bien les injections lorsque l'utilisateur met un début de commentaires pour masquer une condition (WHERE) ou un AND/OR, mais là comme il y a rien derrière le LIKE je vois pas trop ... ?
 
merci en tout cas

Moi ma remarque serait...  
Pourquoi mettre  

sur toutes les pages? Tu mets ça sur la première page et quand tu veux détruire la session tu mets le session

Voilà

parce qu'il faut appeler session_start sur chaque page qui utilisera la session  
 
http://fr.php.net/session_start

euh d'après ce que j'ai lu, on ne peut pas utiliser $_SESSION sur les pages qui ne commencent pas par <?php session_start();
d'où l'obligation de le mettre sur toutes les pages où je me sers des variables sessions
 
Voilà, mais bon si qqn veut confirmer ça serait bien

ah ben grillé

ah si je pense avoir compris : si l'utilisateur finit correctement la requête et en écrit une autre juste derrière ?  
par exemple pour $id :

j'ai bon ?

par contre a la place de like tu mets =  
si t as -exemple bidon- toto et toti comme users ca risque de planter

J'ai rien dit... Vais me recoucher...

ah oui exellent merci

dur dur de s'y mettre un dimanche hein

Si tu est parano:
http://fr2.php.net/crypt
explique comment éviter que les mots de passe soient volés en cas de hack.

Y parait que Joomla securise au niveau militaire ?

tu arrêtes de saouler ton monde avec Joomla ?

 
Y paraît que:
1- "sécurisé au niveau militaire" c'est risible
2- on s'en branle d'un n-ième CMS parmi d'autres qui est juste un fork de Mambo avec une forte dose d'évangélisme

de même tu peux mettre un session_regenerate_id(); lors du log, afin de changer le N° de ta session et donc d'éviter une partie d'un vol de session.

Ouais ...
 
session_regenerate_id : ne detruit pas la session precedente.
 
Au final ton système de session devient une passoire  

 
Suffit de brancher le cerveau et de lire 2 secondes les commentaires dans la doc php.
Ceci dit mea culpa, je pensais que le comportement en php 4 était de détruire quand même la session.

la fonction md5($password) pourra t'être utile pour le cryptage de ton password

oui merci
 
Dailleurs ça m'amène à vous poser une question : que penser des sites qui nous retournent notre mot de passe par mail lorsque l'on clique sur le traditionnel "J'ai oublié mon mot de passe" ?
 
Certains d'entre eux nous renvoient un nouveau mot de passe puisque le notre n'est pas stocké par défaut dans leur bdd, ils ne conservent que la version hashée mais d'autres nous renvoie notre mot de passe en clair... ce qui signifie qu'ils stockent notre pass non hashé dans la bdd ?

 
Soit il est stocké non hashé dans la bdd, soit il est stocké crypté dans la bdd et décrypté uniquement quand tu le demandes. En même temps, si la base est compromise, c'est pas d'avoir hashé le password en md5 qui va apporter une quelconque protection. Ca rend la récupération du password non triviale, mais c'est pas bien compliqué quand même.

 
Ils peuvent le stocker crypté.
Ca permet de s'assurer que si seulement la base de données est compromise,  les mots de passe ne seront pas menacés.
Par contre si le site complet est hacké...
 
PS : pour la sécurisation des scripts et des sessions, sans redonner toutes les techniques (il y a plein de tutoriaux sur le sujet un peu partout), il y a toujours la solution de stocker l'adresse IP dans la session et de la comparer à l'adresse du client à chaque nouvel appel de script. Ca peut déjà éviter pas mal de problèmes...

Weezo > Et ca permet aussi d'empécher l'accés aux zones protégés à ceux qui voient leurs Ip changer n'importe quand (AOL bonjour)

 
Déjà proposé sur un autre topic, mais quelqu'un a fait remarquer à juste titre que les usagers d'AOL en feront les frais (puisque leur connexion peut passer par divers proxies qui changent en continu).

Les stocker en clair c'est de l'hérésie
 
Si la base est compromise, tu feras pas grand chose d'un hash A moins d'avoir vraiment beaucoup à gagner et d'avoir aussi le script, beaucoup de temps à perdre sans garantie et surtout une puissance de calcul suffisante

Spa bien ça, ne serait - ce que par principe, même si t'as accès aux données sans le dit mdp, je veux pas connaitre le mdp de qui que ce soit

 
Pas faire grand chose d'un hash ? Si la fonction de hachage a été appliquée bêtement comme c'est le cas dans la grosse majorité des cas, un procédé comme les rainbow tables permet de trouver un mot de passe sans avoir besoin d'une puissance de calcul énorme, et ce dans des temps raisonnables.
 
Donc oui c'est parfaitement exploitable un hash. Après on peut effectivement éviter ce genre de problèmes. En mettant du "sel" (cf article wikipedia) par exemple ou en utilisant autre chose qu'une fonction de hachage (cryptage).
Faut pas croire que ça n'arrive que dans des films. Sur le site web de ma guilde de MMO, une appli php non sécurisée (associée à une mauvaise configuration du cookie du forum) a permis à un mec de voler le cookie de forum de l'admin contenant le hash md5 du password, puis il a retrouvé le pass par une attaque à la rainbow table, et il a foutu le bordel tant qu'il a pu.
 
Donc la sécurité apportée par un hachage de password dans la BDD, c'est tout relatif.
Edit: après, pour simplement le masquer aux yeux de personnes de confiance, dont l'admin de la BDD, oui.

C'est pour ça que j'aurais tendance à dire... chiffrement du mot de passe par un algorithme à sens unique, et éventuellement avec un salt aléatoire en plus. la possibilité de retrouver le mot de passe original est proche de 0 même avec le mot de passe crypter et le salt. (crypt(motdepasse, '$2$0123456789012'); )

Je ne connaissais pas l'existence de ses rainbow tables   MAintenant on est d'accord que de toutes manières, quand on parle de sécurité il faut pas se satisfaire du minimum
 
De toutes manières si le vol de session/cookie est rendu quasi impossible et le serveur/script sécurisé comme il faut, le risque de se faire voler quoi que ce soit est largement assez faible si t'as pas des dossiers secret/défense à cacher
 
Puis un détail con, celui qui veut facilement un mdp, il a qu'à le ramasser au moment où il est encore en clair s'il le veut vraiment  

 
Attention à toujours garder un certain sens de la mesure au niveau sécurité. Le cas concret auquel j'ai été confronté, c'est un mec avec un minimum de connaissances qui voulait vandaliser un site. Et il a réussi. Y'avait rien à voler, aucune info sensible, rien hein. Juste une volonté de mal faire d'un mec. Ca peut arriver à n'importe qui.
 
Après, pour que le mec réussisse à chopper le mot de passe en clair, c'est autre chose, ça requiert d'autres moyens que d'utiliser une faille existante pour se procurer un cookie.

Sur la totalité des sites ( yahoo , google , tous les forums possibles ) le hash est stocke dans un cookie. Avoir ce hash te permet de te logguer sans connaitre le mot de passe. Quelquefois tu px meme changer le pass ou l 'email ou arrivera le mot de passe.
 
J en ai fais pleurer plus d'un avec des cookies forgés. La seule difficulté dans l'attaque étant de trouver ou placer son XSS .
 
En gros tous les sites ou tu vois "mémoriser mon mot de passe" sont des cibles potentielles. De plus il n'y a aucune securisation du cookie en lui meme. En gros tu px très bien mettre en place un brute force qui fonctionnera à plein pot en passant par les cookies plutot que le formulaire ( qui lui a souvent la mauvaise tendance a etre plus securisé qu'ailleurs ).

Une question sur mysql_real_escape_string :
 
Faut t-il mettre pour, par exemple la variable $utilisateur :
 
- Ca : $utilisateur = mysql_real_escape_string($utilisateur);
- Ou bien : mysql_real_escape_string($utilisateur);

Joomla est juste un CMS, bourré de failles qui plus est et aucun rapport avec le topic ...

 
Lis la doc    
 
Valeurs de retour
Retourne la chaîne échappée (...)

  merci