je comprend pas trop l'interet de chiffrer tes mots de passe... t'es de la CIA ? tu les stock comment et ou tes mots de passes...illicoo a dit:
illicoo a dit:
Vladrow a dit:Elle est au plus simple. Et c'est la meilleure que tu puisses avoir simplement avec free.
Effectivement si tu ne quittes pas le navigateur, tu restes connecté au site.
Tout dépends du niveau de sécurité que tu désires et des conditions d'utilisations de ton ordinateur.
La quasi totalité des internautes ne pourra pas accéder au site sans le mot de passe.
Un hyper crack passera toujours.
Evidemment si tu ne ferme jamais ton navigateur et si tu ne souhaites pas qu'un utilisateur de ton ordinateur puisse accéder au site, on quitte les méthodes simples et tu dois trouver une méthode de "dés-identification", comme les sites sécurisés des banques. Là, je passe. :siffle:
Mais il me semble aussi simple de quitter le navigateur
Et puis si c'est vraiment important, tu dois penser au cryptage des données des pages pendant le transfert, etc. etc. etc. A toi de régler ton besoin de sécurité par rapport à la simplicté et au coût.
![[MGZ]Slug](/data/avatars/m/0/55.jpg?1089234184){kind=avatar}
De plus, c'est franchement simple a mettre en place.[MGZ]Slug a dit:Si tu utilises PHP, tu utilises des formulaires, des requetes SQL ou vers un fichier, etc ... bref, il y a des dizaines de façon de contourner une protection PHP si le code ne tient pas compte de certaines mesures de sécurité. Cela demande pas mal de temps pour avoir un truc qui tienne vraiment la route, et pas mal de recherches si on débute.
Avec un .htaccess, tout se passe directement au niveau du serveur Web, et a moins de s'y attaquer avec un brute force, ou trouver une faille directement dans Apache ... je ne vois pas comment passer outre
mxmac a dit:
Toutefois je vous conseille de vous renseigner sur cette technique, et sur les autres, de façon a être en mesure de vous en protéger.[MGZ]Slug a dit:Il y a généralement moyen de modifier le comportement des scripts php en mettant certains infos dans les champs d'un formulaire.
On prend le cas le plus basique de chez basique. Le formulaire d'identification avec stockage des infos dans une base MySQL ! Un champ login, un champ password.
Généralement quand tu débutes avec ce genre de trucs tu recupères les données de tes champs via $_POST['login'] et $_POST['password'], et tu colles tout ça dans une requete MySQL mal fichue (pas de quotes, etc...).
"SELECT * FROM users WHERE login=".$_POST['login']." AND password=".$_POST['password']
Et tu testes si ça renvois quelque chose pour donner ou non acces a la page. La requete est peut-etre mal fichue, mais dans l'ensemble, ça ne parait pas poser de problème particulier de sécurité. Et pourtant si ... imagines que tu ais mis dans le champs password :
1 AND 1=1
La requete devient
SELECT * FROM users WHERE login=xxx AND password=1 AND 1=1
En gros, tu as une requete qui dis : selectionnes tout ou c'est vrai. Bref, il selectionne tout et le gars rentre dans la page sans meme s'etre cassé la tete.
Cas encore plus vicieux ... dans le champs login tu mets :
1; DROP TABLE `users`; COMMIT; --
La requete devient
SELECT * FROM users WHERE login=1; DROP TABLE `users`; COMMIT; -- AND password=1 AND 1=1
Une requete qui se transforme en trois requete, et ta table users qui disparait ! Et même pas de message d'erreur car la partie apres le -- est commenté.
Pour palier à ce genre de probleme il faut bien construire ses requetes pour emmerder le vilain mechant potentiel :
SELECT * FROM `users` WHERE `login` = 'xxx' AND `password` = 'yyyyy'
Secondo il faut vérifier le login, et le password entré dans le champ avant de les passer dans la requete. Pour les vérifications il faut tout d'abord virer tous les caractères ', ou tout du moins les transformet en \'. Pourquoi ? Pour obliger le vilain à mettre ses donnees vicieuses entre apostrophes :
1' AND 1=1
Si tu transforme le ' en \' la requete sql devient
SELECT * FROM `users` WHERE `login` = 'xxx' AND `password` = '1\' AND 1=1
Ce qui n'est pas une requete valide car il n'y a pas d'apostrophe de fin. bref MySQL ne va rien faire.
Ensuite il faut se prévenir des --, et autres ; ... bref il faut tripatouiller les infos pour etre sur que c'est de la forme demandée.
A chaque fois que l'on demande des infos venant de l'utilisateur, il faut absolument penser à un systeme qui ne soit pas détournable, et tester toutes les infos. C'est faisable, mais ça demande de farfouiller sur le net, et de faire des tests ... beaucoup de tests
mxmac a dit:
De plus le nom des tables n'est pas forcement utile. Tout depend de la requete.
Halbert a dit:
mxmac a dit:
[MGZ]Slug a dit:Soit tu mets un @, soit tu bidouilles le php.ini. Bref, le @ c'est bien. Et il faut aussi éviter d'afficher les mysql_error() a moins que l'utilisateur soit un admin par exemple, ou que le site soit en mode "debug".
Je vais essayer de regrouper de la doc en français sur les bonnes habitudes a prendre pour sécuriser un petit peu les sites php
@+
Guillaume
